Do rozpoczęcia nowego przepływu w tym tempie pozostało kilka dni z OTUS. W związku z tym chcielibyśmy udostępnić Państwu tłumaczenie przydatnych materiałów na ten temat.
Seria wpisów na blogu zawierających porady i wskazówki dotyczące rozwiązywania problemów z pingiem IPv6 (żądanie echa/odpowiedź echa ICMPv6)
Pamiętaj, że używam Linuksa (w szczególności Fedory 31), jednak składnia polecenia ping dla innych systemów operacyjnych powinna być bardzo podobna.
Pinguj wszystkie węzły IPv6 na kanale
Pierwszą i najprostszą wskazówką jest wysłanie polecenia ping do wszystkich węzłów IPv6 na łączu.
IPv6 wykorzystuje adresy multiemisji do wszystkich typów komunikacji jeden do wielu. Nie ma adresów rozgłoszeniowych (lub rozgłoszeniowych) IPv6. To odróżnia IPv6 od IPv4, gdzie istnieje kilka typów adresów rozgłoszeniowych, na przykład adres „ograniczonej emisji” 255.255.255.255 [RFC1122].
Istnieje jednak adres IPv6 obejmujący multiemisję wszystkich węzłów, więc użyjemy go do pingowania wszystkich węzłów IPv6 na łączu. (Adres „rozgłoszeniowy” to tak naprawdę po prostu specjalnie nazwany adres multiemisji, który stanowi grupę multiemisji zawierającą wszystkie węzły. Należy zauważyć, że na przykład bit „grupy” lub adresu multiemisji jest włączony w adresach rozgłoszeniowych Ethernet w warstwie łącza ).
Adres IPv6 multiemisji wszystkich węzłów dla kanału: ff02::1. ff oznacza adres IPv6 multiemisji. Następne 0 to część flagi z nieustawionymi bitami.
Dalej 2 definiuje obszar grupy multicast. W przeciwieństwie do adresów multiemisji IPv4, adresy multiemisji IPv6 mają zakres. Wartość zakresu wskazuje część sieci, przez którą pakiet multiemisji może być przekazywany dalej. Gdy pakiet osiągnie granicę określonego zakresu, pakiet musi zostać odrzucony, niezależnie od tego, czy jego pole licznika przeskoków jest różne od zera. Oczywiście, jeśli liczba przeskoków osiągnie zero przed osiągnięciem określonej granicy grupy multiemisji, jest ona również natychmiast resetowana. Oto pełna lista zakresu multiemisji IPv6.
Wreszcie, ::1 określa grupę multiemisji obejmującą wszystkie węzły.
O adresie ff02::1 Warto zaznaczyć, że jest to niejednoznaczne. Na hoście IPv6 z wieloma interfejsami, takim jak router lub host wieloadresowy, adres ff02::1 nie ma żadnego miejsca, w którym można określić, do którego interfejsu mają być wysyłane żądania echa ICMPv6 lub oczekiwać otrzymania odpowiedzi echa ICMPv6 po ich nadejściu. ff02::1 jest ważny i może być używany na dowolnym interfejsie i kanale podłączonym do węzła z wieloma interfejsami.
Kiedy więc pingujemy wszystkie węzły IPv6 na łączu, musimy w jakiś sposób poinformować o tym narzędzie ping dla protokołu IPv6, jakiego interfejsu użyć.
Definiowanie interfejsów – opcja wiersza poleceń
Jak już widzieliśmy, adres multiemisji obejmujący wszystkie węzły, którego chcemy użyć, to - ff02::1 - nie dostarcza żadnych informacji odnośnie tego, który interfejs ma wysyłać i odbierać pakiety żądania echa i odpowiedzi ICMPv6.
Jak zatem określić interfejs, który będzie używany dla przestrzeni adresowej multiemisji lub przestrzeni adresowej Link-Local emisji pojedynczej?
Pierwszym i najbardziej oczywistym sposobem jest podanie go jako parametru aplikacji, z której korzystamy.
Dla użyteczności ping zapewniamy to poprzez opcję -I.
[mark@opy ~]$ ping -w 1 -I enp3s2 ff02::1
ping: Warning: source address might be selected on device other than: enp3s2
PING ff02::1(ff02::1) from :: enp3s2: 56 data bytes
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 ms
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.589 ms (DUP!)
64 bytes from fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=5.15 ms (DUP!)
64 bytes from fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=58.0 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=62.3 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=62.8 ms (DUP!)
--- ff02::1 ping statistics ---
1 packets transmitted, 1 received, +5 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.438/31.544/62.786/29.566 ms
[mark@opy ~]$Korzystając z tego polecenia ping multiemisji obejmującego wszystkie węzły, otrzymaliśmy odpowiedzi z 6 węzłów IPv6. Odpowiedzi pochodziły z adresów węzłów Link-Local IPv6, zaczynając od prefiksu fe80::/10.
Że ping nie wysyła żądań echa ICMPv6 w nieskończoność, dopóki tego nie przerwiemy, zwykle określamy liczbę pakietów do wysłania za pomocą opcji -c. Jednakże zapobiega to również akceptowaniu i wyświetlaniu przez ping więcej niż jednej odpowiedzi echa ICMPv6 podczas wysyłania żądania echa ICMPv6 multiemisji. Zamiast tego użyliśmy opcji -w, aby określić, że ping powinien zakończyć się po 1 sekundzie, niezależnie od liczby wysłanych lub odebranych żądań echa ICMPv6 lub odpowiedzi echa.
Kolejną rzeczą, na którą warto zwrócić uwagę, jest (DUP!) wynik drugiej i kolejnych odpowiedzi. Pakiety te są identyfikowane jako zduplikowane odpowiedzi, ponieważ mają tę samą wartość sekwencji ICMP, co indywidualne żądania echa ICMPv6, które zostały wysłane w pierwszej kolejności. Pojawiają się, ponieważ żądanie echa multiemisji ICMPv6 skutkuje wieloma indywidualnymi odpowiedziami emisji pojedynczej. Liczba duplikatów jest również wskazana w podsumowaniu statystyk.
Definiowanie interfejsów - ID strefy
Innym sposobem udostępnienia interfejsu do użycia jest dodanie go jako części parametru adresu IPv6.
Przykład tego możemy zobaczyć w wynikach polecenia ping, gdzie adresy odpowiadających hostów IPv6 również mają przyrostek %enp3s2na przykład:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msTa metoda określania interfejsów jest formalnie opisana w [RFC4007], „Architektura adresu zdefiniowanego IPv6”. Chociaż zwykle nazywa się je interfejsem systemu operacyjnego, w rzeczywistości definiują coś bardziej ogólnego — „strefę” lub „zakres”.
Powodem posiadania bardziej ogólnych stref lub stref zasięgu jest to, że, jak wspomniano w [RFC4007], węzeł IPv6 może mieć kilka różnych interfejsów IPv6 podłączonych do tego samego kanału. Interfejsy te są członkami tej samej strefy.
Powinna istnieć możliwość grupowania wielu interfejsów w ramach jednej strefy pod systemem operacyjnym; Obecnie nie wiem, czy jest to możliwe pod Linuksem i jak to zrobić.
Używanie przyrostka %<zone_id>, możemy usunąć opcję wiersza poleceń -I ping.
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.606 ms (DUP!)
64 bytes from fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=6.23 ms (DUP!)
64 bytes from fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=157 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=159 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=161 ms (DUP!)
64 bytes from fe80::23d:e8ff:feec:958c%enp3s2: icmp_seq=1 ttl=64 time=179 ms (DUP!)
--- ff02::1%enp3s2 ping statistics ---
1 packets transmitted, 1 received, +7 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.106/82.858/179.216/81.281 ms
[mark@opy ~]$Odpowiedzi na adresy łącza lokalnego
W wyniku tego polecenia ping multiemisji obejmującego wszystkie węzły otrzymaliśmy w sumie 6 unikalnych odpowiedzi.
Odpowiedzi te pochodziły z adresów hostów Link-Local IPv6 typu unicast. Oto na przykład pierwsza odpowiedź:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msAdresy Unicast Link-Local IPv6 są wymagane we wszystkich interfejsach obsługujących protokół IPv6 [RFC4291], „Architektura adresowania IP w wersji 6”. Dzieje się tak dlatego, że węzeł IPv6 zawsze automatycznie posiada adres IPv6 emisji pojedynczej, którego może przynajmniej używać do komunikacji z innymi węzłami za pośrednictwem bezpośrednio połączonych łączy. Obejmuje to komunikację z aplikacjami na innych hostach za pośrednictwem adresów hostów Link-Local.
Upraszcza to projektowanie i wdrażanie protokołów, takich jak IPv6 Neighbor Discovery i OSPFv3. Umożliwia także aplikacjom użytkowników końcowych na hostach komunikację przez kanał bez konieczności stosowania w kanale innej infrastruktury obsługującej protokół IPv6. Bezpośrednia komunikacja między podłączonymi hostami IPv6 nie wymaga routera IPv6 ani serwera DHCPv6 na połączeniu.
Adresy Link-Local zaczynają się od 10-bitowego prefiksu fe80, po których następują 54 bity zerowe, a następnie 64-bitowy identyfikator interfejsu (IID). W powyższej pierwszej odpowiedzi 2392:6213:a15b:66ff jest 64-bitowym identyfikatorem IID.
Zapętlona transmisja multiemisji
Domyślnie pakiety multiemisji są zwracane wewnętrznie do węzła, który je wysłał. Dzieje się tak zarówno w przypadku adresowania IPv6, jak i IPv4.
Powodem tego domyślnego zachowania jest to, że podczas wysyłania pakietów multiemisji może również działać nasłuchująca lokalna aplikacja multiemisji działająca na samym hoście wysyłającym, a także gdzieś w sieci. Ta aplikacja lokalna musi również odbierać pakiety multiemisji.
W wynikach polecenia ping możemy zobaczyć tę lokalną pętlę multiemisji:
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
...Pierwsza i najszybsza odpowiedź (0,106 ms w porównaniu do 0,453 ms) pochodzi z adresu Link-Local skonfigurowanego w samym interfejsie enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Użyteczność ping zapewnia sposób tłumienia lokalnego sprzężenia zwrotnego multiemisji za pomocą parametru -L. Jeśli wyślemy ping multiemisji do wszystkich węzłów z tą flagą, odpowiedzi będą ograniczone do zdalnych węzłów. Nie otrzymujemy odpowiedzi z adresu Link-Local interfejsu wysyłającego.
[mark@opy ~]$ ping -L -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.383 ms
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.467 ms (DUP!)
...Ping Link — adresy lokalne
Jak można się domyślić, same adresy Link-Local emisji pojedynczej również nie dostarczają wystarczających informacji, aby wskazać, jakiego interfejsu użyć, aby się z nimi skontaktować. Podobnie jak w przypadku pingu multiemisji obejmującego wszystkie węzły, musimy również określić interfejs jako parametr wiersza poleceń ping lub identyfikator strefy z adresem podczas pingowania adresów Link-Local.
Tym razem możemy skorzystać -caby ograniczyć liczbę wysyłanych i odbieranych pakietów oraz odpowiedzi ping, ponieważ wykonujemy polecenie ping typu unicast.
[mark@opy ~]$ ping -c 1 fe80::f31c:ccff:fe26:a6d9%enp3s2
PING fe80::f31c:ccff:fe26:a6d9%enp3s2(fe80::fad1:11ff:feb7:3704%enp3s2) 56 data bytes
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.395 ms
--- fe80::f31c:ccff:fe26:a6d9%enp3s2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.395/0.395/0.395/0.000 ms
[mark@opy ~]$Pingować (wszystkie) inne adresy IPv6?
W tym artykule widzieliśmy, jak pingować wszystkie węzły IPv6 na kanale przy użyciu adresu IPv6 multiemisji obejmującego wszystkie węzły ff02::1. Widzieliśmy także, jak określić, który interfejs ma być używany z adresem IPv6 multiemisji obejmującym wszystkie węzły, ponieważ sam adres nie może dostarczyć takich informacji. Użyliśmy jednej z opcji wiersza poleceń pinglub określić interfejs za pomocą przyrostka %<zone_id>.
Następnie dowiedzieliśmy się o adresach Link-Local emisji pojedynczej, które są adresami używanymi do odpowiadania na żądania echa ICMPv6 multiemisji wszystkich węzłów.
Widzieliśmy również, jak domyślnie pakiety multiemisji są zwracane do węzła wysyłającego i jak wyłączyć tę funkcję w narzędziu ping.
Na koniec pingowaliśmy pojedynczy adres Link-Local, używając sufiksu %<zone_id>, ponieważ same adresy Link-Local również nie dostarczają informacji o interfejsie wychodzącym.
A co powiesz na pingowanie wszystkich pozostałych węzłów i uzyskanie ich globalnych adresów emisji pojedynczej (GUA) (czyli ich adresów publicznych w Internecie) lub unikalnych lokalnych adresów emisji pojedynczej (ULA)? Przyjrzymy się temu w następnym poście na blogu.
To wszystko.
Więcej o naszym kursie można dowiedzieć się na stronie.
Źródło: www.habr.com