Zbývá několik dní do zahájení nového cyklu kurzu od OTUS. V této souvislosti bychom s vámi chtěli sdílet překlad užitečného materiálu na toto téma.
Série článků v blogu zaměřených na tipy a doporučení pro odstraňování problémů souvisejících s pingem IPv6 (ICMPv6 Echo Request/Echo Reply)
Všimněte si, že používám Linux (zejména Fedora 31), ale syntaxe příkazu ping by měla být velmi podobná i v jiných operačních systémech.
Ping všech uzlů IPv6 na kanálu
První a nejjednodušší rada — pingnout všechny uzly IPv6 na kanálu.
IPv6 používá multicastové adresy pro všechny typy komunikace „jeden k mnoha“. Neexistují žádné broadcastové IPv6 adresy. To odlišuje IPv6 od IPv4, kde existuje několik typů broadcastových adres, například „limited broadcast“ adresa 255.255.255.255 [RFC1122].
Existuje však „all-nodes multicast“ (obecná multicast) IPv6 adresa, a proto ji použijeme k pingu všech uzlů IPv6 na kanálu. („Broadcast“ adresa je ve skutečnosti jen speciálně pojmenovaná multicastová adresa, která je skupinou multicastového rozesílání zahrnující všechny uzly. Všimněte si, že například bit „skupiny“ nebo multicastové adresy je zahrnut v broadcastových adresách Ethernet na úrovni kanálu).
All-nodes multicast IPv6 adresa pro kanál: ff02::1. ff označuje multicastovou IPv6 adresu. Další 0 je částí flagu s nenastavenými bity.
Dále 2 určuje oblast multicastové skupiny. Na rozdíl od multicast IPv4 adres mají multicast IPv6 adresy scope (oblast viditelnosti). Hodnota scope určuje část sítě, přes kterou je povoleno přesměrovávat multicastový paket. Jakmile paket dosáhne hranice daného scope, musí být paket odmítnut, bez ohledu na to, zda je jeho pole počítadla skoků (Hop Count) nenulové. Samozřejmě, pokud počítadlo skoků dosáhne nuly dříve, než dosáhne dané hranice multicastové skupiny, je také okamžitě zahozen. Zde je úplný seznam multicast scope IPv6.
Nakonec ::1 označuje all-nodes multicast skupinu.
O adrese ff02::1 je třeba poznamenat, že je nejednoznačná. Na zařízení IPv6 s více rozhraními, jako je router nebo multihost, je v adrese ff02::1 Není nic, kde bychom mohli uvést, na jaké rozhraní posílat ICMPv6 echo požadavky nebo očekávat příjem ICMPv6 echo odpovědí, když přicházejí. ff02::1 je platný a může být použit na kterémkoli z rozhraní a kanálů připojených k multi-rozhraní uzlu.
Proto, když provádíme ping na všechny uzly IPv6 na kanálu, potřebujeme nějakým způsobem také informovat nástroj ping o tom, které rozhraní použít pro IPv6.
Definování rozhraní — je to parametr příkazového řádku.
Jak jsme již viděli, multicast adresa all-nodes, kterou chceme použít — ff02::1 — neposkytuje žádné informace o tom, na jaké rozhraní posílat a přijímat ICMPv6 echo požadavky a echo odpovědi.
Tak jak můžeme určit rozhraní, které bude použito pro multicast adresy nebo unicast Link-Local adresy?
První a nejzřejmější způsob je poskytnout jej jako argument pro aplikaci, kterou používáme.
Pro nástroj ping to poskytujeme pomocí volby -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 ~]$Pomocí tohoto all-nodes multicast pingu jsme obdrželi odpovědi od 6 IPv6 uzlů. Odpovědi přišly z uzlových Link-Local IPv6 adres počínaje prefixem fe80::/10.
Aby ping neposílal jsme nekonečně ICMPv6 echo požadavků, dokud jsme jej nepřerušili, obvykle uvádíme počet paketů k odeslání pomocí volby -c. Nicméně to také neumožňuje nástroji ping přijmout a zobrazit více než jednu ICMPv6 echo odpověď při odesílání multicast ICMPv6 echo požadavku. Místo toho jsme použili parametr -w, abychom určili, že ping by měl skončit po 1 sekundě, bez ohledu na to, kolik ICMPv6 echo požadavků nebo echo odpovědí bylo odesláno nebo přijato.
Další věc, na kterou je třeba dávat pozor, je (DUP!) výstup ve druhých a dalších odpovědích. Tyto pakety jsou identifikovány jako duplikáty odpovědi, protože mají stejnou hodnotu ICMP sekvence jako jednotlivé echo požadavky ICMPv6, které byly odeslány jako první. Objevují se, protože multicast echo požadavek ICMPv6 vede k několika jednotlivým unicast odpovědím. Počet duplikátů je také uveden ve shrnutí statistik.
Definice rozhraní — Zone ID
Další způsob, jak poskytnout rozhraní pro použití, je součástí parametru adresy IPv6.
Můžeme to vidět na výstupu ping, kde adresy odpovídajících IPv6 uzlů také mají příponu %enp3s2, například:
64 bajtů z fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 čas=0.438 msTento způsob určení rozhraní je formálně popsán v [RFC4007], „Architektura se specifikovanými adresami IPv6“. Ačkoli jsou obvykle nazývány rozhraním operačního systému, ve skutečnosti určují něco obecnějšího — „zónu“ nebo „oblast působnosti“.
Důvod existence obecnějších zón nebo oblastí působnosti je, že jak zmiňuje [RFC4007], uzel IPv6 může mít několik různých IPv6 rozhraní připojených ke stejnému kanálu. Tato rozhraní jsou členy jedné zóny.
Mělo by být možné seskupit několik rozhraní v rámci zóny pod operačním systémem; v současné době nevím, zda je to možné pod Linuxem a jak to udělat.
Použitím přípony %, můžeme odstranit parametr příkazového řádku -I ping.
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 datových bajtů
64 bajtů z fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 čas=0.106 ms
64 bajtů z fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 čas=0.453 ms (DUP!)
64 bajtů z fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 čas=0.606 ms (DUP!)
64 bajtů z fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 čas=6.23 ms (DUP!)
64 bajtů z fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 čas=157 ms (DUP!)
64 bajtů z fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 čas=159 ms (DUP!)
64 bajtů z fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 čas=161 ms (DUP!)
64 bajtů z fe80::23d:e8ff:feec:958c%enp3s2: icmp_seq=1 ttl=64 čas=179 ms (DUP!)
--- ff02::1%enp3s2 ping statistiky ---
1 paket odeslán, 1 přijat, +7 duplikátů, 0% ztráta paketů, čas 0ms
rtt min/avg/max/mdev = 0.106/82.858/179.216/81.281 ms
[mark@opy ~]$Odpovědi Link-Local adresů
Z tohoto multicast pingu all-nodes jsme obdrželi celkem 6 unikátních odpovědí.
Tyto odpovědi pocházely z unicast Link-Local adresů uzlů IPv6. Například, zde je první odpověď:
64 bajtů z fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 čas=0.106 msUnicastové Link-Local IPv6 adresy jsou vyžadovány na všech rozhraních, která podporují IPv6 [RFC4291], „Architektura adresování IP verze 6“. Důvodem je, že IPv6 uzel má vždy automaticky unicastovou IPv6 adresu, kterou může použít minimálně pro komunikaci s jinými uzly přes své přímo připojené kanály. To zahrnuje komunikaci s aplikacemi jiných hostitelů prostřednictvím Link-Local adres hostitelů.
To zjednodušuje vývoj a implementaci protokolů, jako je IPv6 Neighbor Discovery a OSPFv3. Také to umožňuje koncovým uživatelským aplikacím na hostitelích vyměňovat si data přes kanál, aniž by bylo potřeba jakékoli další podpůrné infrastruktury IPv6. Pro přímou komunikaci připojených hostitelů IPv6 není v síti nutný IPv6 router nebo DHCPv6 server.
Link-Local adresy začínají 10bitovým prefixem fe80, za kterým následuje 54 nulových bitů a pak 64bitový identifikátor rozhraní (IID). V první odpovědi výše 2392:6213:a15b:66ff — to je 64bitový IID.
Smyčkový M multicast
Ve výchozím nastavení se multicastové pakety vracejí interně k uzlu, který je odesílá. To platí pro jak IPv6, tak IPv4 adresování.
Příčinou tohoto výchozího chování je to, že při odesílání multicastových paketů může také běžet místní multicastová aplikace na samotném odesílajícím hostiteli, stejně jako někde v síti. Tato místní aplikace by měla také přijímat multicastové pakety.
Tento místní výkon multicastové smyčky můžeme vidět ve výstupu našeho ping:
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 datových bajtů
64 bajtů z fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 čas=0.106 ms
64 bajtů z fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 čas=0.453 ms (DUP!)
...První a nejrychlejší odpověď (0,106 ms ve srovnání s 0,453 ms) přichází z Link-Local adresy nastavené na samotném rozhraní enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Nástroj ping poskytuje způsob potlačení místní zpětné vazby multicastového vysílání pomocí parametru -L. Pokud odešleme ping na multicast všech uzlů s tímto flagem, odpovědi jsou omezeny na vzdálené uzly. Nezískáme odpověď z Link-Local adresy rozhraní odesílatele.
[mark@opy ~]$ ping -L -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 datových bajtů
64 bajtů z fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 čas=0.383 ms
64 bajtů z fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 čas=0.467 ms (DUP!)
...Ping Link-Local Adresy
Jak si můžete domyslet, unicastové Link-Local adresy samy o sobě také neposkytují dostatek informací k určení, který interface použít pro jejich dosažení. Stejně jako v případě all-nodes multicast pingu, také musíme uvést interface jako parametr příkazového řádku ping nebo zone ID s adresou při pingu Link-Local adres.
Tentokrát můžeme použít -c, abychom omezili počet paketů a odpovědí, které jsou odesílány a přijímány ping, protože provádíme unicast ping.
[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 ~]$Pingovat (vše) ostatní IPv6 adresy?
V tomto článku jsme viděli, jak propagovat všechny IPv6 uzly na kanálu pomocí all-nodes multicast IPv6 adresy ff02::1. Také jsme viděli, jak určit, který interface použít s all-nodes multicast IPv6 adresou, protože sama adresa tyto informace poskytnout nemůže. Použili jsme buď parametr příkazového řádku ping, nebo jsme uvedli interface pomocí suffixu %.
Poté jsme se dozvěděli o unicastových Link-Local adresách, které jsou adresy používány k odpovědím na all-nodes multicast echo requests ICMPv6.
Také jsme viděli, jak multicast pakety se vracejí k odesílajícímu uzlu jako výchozí a jak to deaktivovat pro utilitu ping.
Nakonec jsme prověřili individuální Link-Local adresu, používající suffix %, protože Link-Local adresy samy o sobě také neposkytují informace o odchozím interface.
Co takhle pingu všech ostatních uzlů a získání jejich globálních unicast adres (GUA) (tj. jejich veřejných adres na internetu) nebo jejich unikátních lokálních unicast adres (ULA)? To probereme v dalším článku na blogu.
A to je všechno.
Více informací o našem kurzu naleznete v.
Zdroj: habr.com
