Mikrotik - nejde ping na FDQN IPv6 only. Bug nebo featura?

the_max · 2020-04-14T19:42:14+00:00

Pokud zkusím z Winboxu Tool -> Ping třeba na www.seznam.cz tak to samozřejmě projde. Kokud zkusím to samé z shellu, /ping www.seznam.cz tak to také projd...

ef

není to proto že očekává ping překlad jen na A záznam a ne na AAAA. Chtělo by to něco jako ping6.

the_max

Ale proč? Když lezeš na web, tak tě taky nezajímá jestli má 6kunebo 4ku, primárně jdeš po 6ce. Ping už taky (teda alespoň v Linuxu (alespoň u mě na Gentoo)) taky nerolišuje jestli je to 4ka nebo 6ka, primárně zkouší 6ku.
Jako pochopil bych, kdyby tam byl třeba parametr -4 a -6 (stejně jako u pingu, ip, nmapu a všech dalších nástrojích) kde si explicitně můžu vybrat kterou adresu chci, pokud existují obě, ve winboxu by pak mohl být třeba radio button s IPv4 a IPv6 only.
Ale když mi prostě DNSko vrátí pouze 6kovou adresu, no tak prostě zkusím ping na ní.

ef

Co vím tak u debian a Ubuntu musíš použít ping6 pro 6-tku. Jinak pinga po 4ce.

the_max

ef
themax@pve:~# cat /etc/debian_version 10.3 themax@pve:~# ping www.nebezi.cz PING www.nebezi.cz(www.nebezi.cz (2001:1528:132:70::ebe2)) 56 data bytes 64 bytes from www.nebezi.cz (2001:1528:132:70::ebe2): icmp_seq=1 ttl=59 time=5.35 ms 64 bytes from www.nebezi.cz (2001:1528:132:70::ebe2): icmp_seq=2 ttl=59 time=5.79 ms ^C --- www.nebezi.cz ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 3ms rtt min/avg/max/mdev = 5.352/5.571/5.791/0.231 ms themax@pve:~# ping www.seznam.cz PING www.seznam.cz(2a02:598:4444:1::1 (2a02:598:4444:1::1)) 56 data bytes 64 bytes from 2a02:598:4444:1::1 (2a02:598:4444:1::1): icmp_seq=1 ttl=58 time=5.35 ms 64 bytes from 2a02:598:4444:1::1 (2a02:598:4444:1::1): icmp_seq=2 ttl=58 time=7.16 ms ^C --- www.seznam.cz ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 2ms rtt min/avg/max/mdev = 5.354/6.254/7.155/0.903 ms themax@pve:~#
?

ef

Ale cítím to stejně. Ale není to tak.

s_a_m

ef tuhle distribuci ani nezminuj sezere te 🙂 jinak logicky parametr -4 a -6 bohuzel co je u mikrokreteniku logickeho ze 🙂

obud

the_max Těch bugů s IPv6 tam bude víc, já jsem třeba narazil na to, že ve skriptu mi nebyl RouterOS schpný přeložit IPv6 adresu na doménové jméno (reverzní DNS). A přitom vyhledání reverzního záznamu u IPv4 adresy fungovalo.

A nebo třeba binding-script u DHCPv6 serveru v jednom parametru pro skript vrací místo DUID MAC adresu. 😁

ef

_# cat /etc/debian_version
8.11

root@deb:_# ping www.nebezi.cz
ping: unknown host www.nebezi.cz

root@deb_# ping6 www.nebezi.cz
PING www.nebezi.cz(www.nebezi.cz) 56 data bytes
64 bytes from www.nebezi.cz: icmp_seq=1 ttl=59 time=8.01 ms
64 bytes from www.nebezi.cz: icmp_seq=2 ttl=59 time=7.82 ms
64 bytes from www.nebezi.cz: icmp_seq=3 ttl=59 time=8.44 ms
^C
--- www.nebezi.cz ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 7.825/8.092/8.440/0.267 ms

obud

ef
root@server:_# cat /etc/debian_version
9.11
root@server:_# ping www.nebezi.cz
PING www.nebezi.cz(www.nebezi.cz (2001:1528:132:70::ebe2)) 56 data bytes
64 bytes from www.nebezi.cz (2001:1528:132:70::ebe2): icmp_seq=1 ttl=56 time=7.01 ms
64 bytes from www.nebezi.cz (2001:1528:132:70::ebe2): icmp_seq=2 ttl=56 time=9.36 ms
64 bytes from www.nebezi.cz (2001:1528:132:70::ebe2): icmp_seq=3 ttl=56 time=6.83 ms
64 bytes from www.nebezi.cz (2001:1528:132:70::ebe2): icmp_seq=4 ttl=56 time=6.59 ms
64 bytes from www.nebezi.cz (2001:1528:132:70::ebe2): icmp_seq=5 ttl=56 time=6.54 ms
64 bytes from www.nebezi.cz (2001:1528:132:70::ebe2): icmp_seq=6 ttl=56 time=6.63 ms
64 bytes from www.nebezi.cz (2001:1528:132:70::ebe2): icmp_seq=7 ttl=56 time=10.9 ms
64 bytes from www.nebezi.cz (2001:1528:132:70::ebe2): icmp_seq=8 ttl=56 time=6.40 ms

--- www.nebezi.cz ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7004ms
rtt min/avg/max/mdev = 6.403/7.547/10.995/1.586 ms

the_max

pěkné, pěkné. 21. století a tolik bugů. Pak se má IPv6 rozšířit.

obud

the_max pěkné, pěkné. 21. století a tolik bugů. Pak se má IPv6 rozšířit.

Na co jsem narazil za posledních pár měsíců: v UBNT AirOS nefunguje IPv6 routing (ignor ze strany UBNT), Aruba iAP rozbíjí IPv6 autokonfiguraci (nejsou schopni to opravit ani po 6 letech), HPE Comware má několik bugů v IPv6 ACL (jeden bug opravili, je tam další), FortiGate SSL-VPN má rozbitou podporu IPv6 v Android klientovi.

Dále RouterOS nezobrazuje IPv6 adresy získané ze SLAAC, DHCPv6 server nepodporuje přidělování adres, DHCPv6 relay není schopna přidat routu, a tak by se dalo pokračovat...

Nemůžu se zbavit dojmu, že ti výrobci IPv6 vůbec netestují. (Jestli vůbec něco testují.)