Zaledwie kilka dni pozostało do rozpoczęcia nowej edycji kursu od OTUS. W związku z tym chcemy podzielić się z Państwem tłumaczeniem przydatnego materiału na ten temat.
Seria artykułów na blogu poświęconych poradom i rekomendacjom dotyczącym rozwiązywania problemów związanych z pingiem IPv6 (ICMPv6 Echo Request/Echo Reply)
Zauważ, że używam systemu Linux (konkretnie Fedora 31), jednak składnia polecenia ping w innych systemach operacyjnych powinna być bardzo podobna.
Ping wszystkich węzłów IPv6 na kanale
Pierwsza i najprostsza rada – sprawdź pingiem wszystkie węzły IPv6 w sieci.
IPv6 wykorzystuje adresy multicastowe dla wszystkich typów komunikacji „jeden do wielu”. Nie istnieją adresy broadcastowe (lub szerokiego rozgłaszania) IPv6. To odróżnia IPv6 od IPv4, gdzie istnieje kilka typów adresów broadcastowych, na przykład adres „limited broadcast” 255.255.255.255 [RFC1122].
Jednak istnieje adres multicastowy „wszystkie węzły” (all-nodes multicast) IPv6, dlatego będziemy go używać do pingowania wszystkich węzłów IPv6 w sieci. Adres „broadcastowy” jest w rzeczywistości specjalnie nazwanym adresem multicastowym, który jest grupą adresów multicastowych obejmujących wszystkie węzły. Zauważ, że na przykład bit „grupy” lub adresu multicastowego jest uwzględniony w adresach broadcastowych Ethernet na poziomie łącza.
Adres multicastowy all-nodes IPv6 dla sieci: ff02::1. ff oznacza multicastowy adres IPv6. Następny 0 to część flagi z niezdefiniowanymi bitami.
Dalej 2 określa zakres grupy multicastowej. W przeciwieństwie do adresów multicastowych IPv4, adresy multicastowe IPv6 mają scope (zakres widoczności). Wartość scope wskazuje część sieci, przez którą dozwolone jest przesyłanie pakietu multicastowego. Gdy pakiet osiąga granicę określonego scope, powinien zostać odrzucony, niezależnie od tego, czy jego pole licznika przeskoków (Hop Count) jest różne od zera. Oczywiście, jeśli licznik przeskoków osiąga zero przed osiągnięciem granicy grupy multicastowej, również natychmiast zostaje zresetowany. Oto pełna lista zakresów multicastowych IPv6.
Na koniec, ::1 określa grupę multicastową all-nodes.
O adresie ff02::1 należy zauważyć, że jest on niejednoznaczny. Na węźle IPv6 z wieloma interfejsami, takim jak router czy host wielonetworkowy, w adresie ff02::1 Nie ma niczego, co pozwalałoby wskazać, na którym interfejsie wysyłać żądania echa ICMPv6 lub oczekiwać na otrzymanie odpowiedzi echa ICMPv6, gdy te przychodzą. ff02::1 Jest ważny i może być używany na każdym z interfejsów i kanałów podłączonych do węzła z wieloma interfejsami.
Dlatego, gdy pingujemy wszystkie węzły IPv6 na kanale, musimy w jakiś sposób również powiadomić narzędzie ping o tym, który interfejs ma być użyty dla IPv6.
Określenie interfejsów — parametr wiersza poleceń.
Jak już widzieliśmy, multicastowy adres all-nodes, którego chcemy użyć — ff02::1 — nie dostarcza żadnych informacji o tym, na który interfejs mają być wysyłane i odbierane pakiety żądania echa i odpowiedzi echa ICMPv6.
Jak zatem możemy wskazać interfejs, który będzie używany dla przestrzeni adresów multicastowych lub unicastowych Link-Local?
Pierwszym i najbardziej oczywistym sposobem jest podanie go jako parametru dla aplikacji, której używamy.
Dla narzędzia ping podajemy go za pomocą opcji -I.
[mark@opy ~]$ ping -w 1 -I enp3s2 ff02::1
ping: Ostrzeżenie: adres źródłowy może być wybierany na urządzeniu innym niż: enp3s2
PING ff02::1(ff02::1) z :: enp3s2: 56 bajtów danych
64 bajty z fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 czas=0.438 ms
64 bajty z fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 czas=0.589 ms (DUP!)
64 bajty z fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 czas=5.15 ms (DUP!)
64 bajty z fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 czas=58.0 ms (DUP!)
64 bajty z fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 czas=62.3 ms (DUP!)
64 bajty z fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 czas=62.8 ms (DUP!)
--- statystyki pingu ff02::1 ---
1 pakietów wysłano, 1 odebrane, +5 duplikatów, 0% strat pakietów, czas 0ms
rtt min/avg/max/mdev = 0.438/31.544/62.786/29.566 ms
[mark@opy ~]$Dzięki temu multicastowemu pingowi all-nodes otrzymaliśmy odpowiedzi od 6 węzłów IPv6. Odpowiedzi pochodziły z węzłów Link-Local IPv6, zaczynając od prefiksu fe80::/10.
Aby ping nie kontynuował nieskończonego wysyłania żądań echa ICMPv6, dopóki go nie przerwiemy, zwykle wskazujemy liczbę pakietów do wysłania za pomocą opcji -c. Jednak to również nie pozwala na przyjęcie i wyświetlenie więcej niż jednej odpowiedzi echa ICMPv6 podczas wysyłania multicastowego żądania echa ICMPv6. Zamiast tego użyliśmy parametru -w, aby określić, że ping ma kończyć się po 1 sekundzie, niezależnie od tego, ile żądań echa lub odpowiedzi echa ICMPv6 zostało wysłanych lub odebranych.
Jeszcze jedna rzecz, na którą warto zwrócić uwagę, to (DUP!) odpowiedzi na drugim i kolejnych odpowiedziach. Te pakiety są identyfikowane jako duplikaty odpowiedzi, ponieważ mają tę samą wartość sekwencji ICMP, co pojedyncze echa żądania ICMPv6, które zostały wysłane jako pierwsze. Pojawiają się, ponieważ wielokrotny echo request ICMPv6 prowadzi do kilku indywidualnych odpowiedzi unicast. Liczba duplikatów jest również wskazana w podsumowaniu statystyk.
Definicja interfejsów — Zone ID
Kolejny sposób dostarczania interfejsu do użycia to część parametru adresu IPv6.
Możemy zaobserwować przykład tego w wynikach ping, gdzie adresy odpowiadających węzłów IPv6 mają również sufiks. %enp3s2, na przykład:
64 bajty z fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 czas=0.438 msTen sposób definiowania interfejsów jest formalnie opisany w [RFC4007], „Architektura adresów IPv6”. Chociaż zazwyczaj nazywane są interfejsem systemu operacyjnego, w rzeczywistości definiują coś bardziej ogólnego — „strefę” lub „zakres”.
Powód istnienia bardziej ogólnych stref lub stref zakresu polega na tym, że, jak wspomniano w [RFC4007], węzeł IPv6 może mieć kilka różnych interfejsów IPv6 podłączonych do tego samego kanału. Te interfejsy są członkami jednej strefy.
Powinno być możliwe grupowanie kilku interfejsów w ramach strefy pod systemem operacyjnym; obecnie nie wiem, czy to możliwe w systemie Linux i jak to zrobić.
Używając sufiksu %, możemy usunąć parametr wiersza poleceń -I ping.
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 danych bajtów
64 bajty z fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 czas=0.106 ms
64 bajty z fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 czas=0.453 ms (DUP!)
64 bajty z fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 czas=0.606 ms (DUP!)
64 bajty z fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 czas=6.23 ms (DUP!)
64 bajty z fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 czas=157 ms (DUP!)
64 bajty z fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 czas=159 ms (DUP!)
64 bajty z fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 czas=161 ms (DUP!)
64 bajty z fe80::23d:e8ff:feec:958c%enp3s2: icmp_seq=1 ttl=64 czas=179 ms (DUP!)
--- statystyki ping ff02::1%enp3s2 ---
1 pakiet wysłany, 1 odebrany, +7 duplikatów, 0% strat pakietów, czas 0ms
rtt min/avg/max/mdev = 0.106/82.858/179.216/81.281 ms
[mark@opy ~]$Odpowiedzi Link-Local adresów
Z tego multicastowego pingu all-nodes otrzymaliśmy w sumie 6 unikalnych odpowiedzi.
Te odpowiedzi pochodziły z unicastowych Link-Local adresów węzłów IPv6. Na przykład, oto pierwsza odpowiedź:
64 bajty z fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 czas=0.106 msAdresy IPv6 Link-Local są wymagane na wszystkich interfejsach obsługujących IPv6 [RFC4291], "Architektura adresowania wersji IP 6". Powodem tego jest to, że węzeł IPv6 zawsze automatycznie ma unicastowy adres IPv6, który może wykorzystywać przynajmniej do komunikacji z innymi węzłami przez swoje bezpośrednio podłączone kanały. Obejmuje to komunikację z aplikacjami innych hostów przez adresy Link-Local hostów.
Ułatwia to opracowywanie i wdrażanie protokołów, takich jak IPv6 Neighbor Discovery oraz OSPFv3. Umożliwia to również aplikacjom końcowych użytkowników na hostach wymianę danych przez kanał, nie wymagając żadnej innej wspierającej infrastruktury IPv6 na tym kanale. Do bezpośredniej komunikacji podłączonych hostów nie jest wymagany router IPv6 ani serwer DHCPv6 w połączeniu.
Adresy Link-Local zaczynają się od 10-bitowego prefiksu fe80, po którym następuje 54 zera, a następnie 64-bitowy identyfikator interfejsu (IID). W powyższym pierwszym odpowiedzi 2392:6213:a15b:66ff — to 64-bitowy IID.
Multicast Looped
Domyślnie pakiety multicastowe są zwracane wewnętrznie do węzła, który je wysyła. Dzieje się tak zarówno w adresowaniu IPv6, jak i IPv4.
Powodem tego domyślnego zachowania jest to, że podczas wysyłania pakietów multicastowych może istnieć lokalna aplikacja multicastowa nasłuchująca, pracująca na samym hoste wysyłającym, tak jak gdzieś w sieci. Ta lokalna aplikacja również musi odbierać pakiety multicastowe.
Możemy zobaczyć ten lokalny cykl multicastu w naszym wyniku ping:
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 bajtów danych
64 bajty od fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 czas=0,106 ms
64 bajty od fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 czas=0,453 ms (DUP!)
...Pierwsza i naj szybsza odpowiedź (0,106 ms w porównaniu do 0,453 ms) pochodzi z adresu Link-Local skonfigurowanego na samym interfejsie enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Narzędzie ping oferuje sposób na tłumienie lokalnego sprzężenia zwrotnego rozsyłania multicastowego za pomocą parametru -L. Jeśli wysyłamy ping do multicastu all-nodes z tym flagą, odpowiedzi ograniczają się do zdalnych węzłów. Nie otrzymujemy odpowiedzi z adresu Link-Local interfejsu nadawcy.
[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!)
...Pingowanie adresu Link-Local
Jak można się domyślić, unicastowe adresy Link-Local same w sobie również nie dostarczają wystarczających informacji, aby wskazać, który interfejs wykorzystać do ich osiągnięcia. Podobnie jak w przypadku pingu multicast all-nodes, musimy również wskazać interfejs jako parametr wiersza poleceń. ping lub identyfikator strefy z adresem przy pingowaniu adresów Link-Local.
Tym razem możemy użyć -c, aby ograniczyć liczbę pakietów i odpowiedzi, które są wysyłane i odbierane ping, ponieważ wykonujemy ping unicastowy.
[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 statystyki pingu ---
1 pakiet został wysłany, 1 odebrany, 0% utraty pakietów, czas 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 zobaczyliśmy, jak pingować wszystkie węzły IPv6 w sieci, korzystając z adresu multicast all-nodes IPv6. ff02::1Zobaczyliśmy również, jak wskazać, który interfejs użyć z adresem multicast all-nodes IPv6, ponieważ sam adres nie jest w stanie dostarczyć tych informacji. Użyliśmy albo parametru wiersza poleceń, ping, albo określiliśmy interfejs przez sufiks %.
Następnie dowiedzieliśmy się o unicastowych adresach Link-Local, które są używane do odpowiedzi na wymagania multicast all-nodes ICMPv6.
Zobaczyliśmy również, jak pakiety multicast są domyślnie zwracane do węzła wysyłającego i jak to wyłączyć dla narzędzia. ping.
Na koniec pingowaliśmy pojedynczy adres Link-Local, używając sufiksu %, ponieważ adresy Link-Local same w sobie również nie dostarczają informacji o wychodzącym interfejsie.
A co z pingowaniem wszystkich innych węzłów i uzyskiwaniem ich globalnych adresów unicast (GUA) (tj. ich publicznych adresów w Internecie) lub ich unikalnych lokalnych adresów unicast (ULA)? Temat ten omówimy w następnej części bloga.
Na tym kończymy.
Dowiedz się więcej o naszym kursie w.
Źródło: habr.com
