Niekoľko dní zostáva do začiatku nového prietoku rýchlosťou od spoločnosti OTUS. V tejto súvislosti by sme sa s vami radi podelili o preklad užitočného materiálu na túto tému.
Séria blogových príspevkov o tipoch a trikoch na riešenie problémov IPv6 ping (ICMPv6 Echo Request/Echo Reply)
Upozorňujeme, že používam Linux (konkrétne Fedora 31), avšak syntax príkazu ping pre iné operačné systémy by mala byť, dúfajme, veľmi podobná.
Otestujte všetky uzly IPv6 na kanáli
Prvým a najjednoduchším tipom je ping na všetky uzly IPv6 na odkaze.
IPv6 používa multicast adresy pre všetky typy komunikácie typu one-to-many. Neexistujú žiadne vysielacie (alebo vysielacie) adresy IPv6. To odlišuje IPv6 od IPv4, kde existuje niekoľko typov vysielacích adries, napríklad adresa „obmedzeného vysielania“ 255.255.255.255 [RFC1122].
Existuje však adresa IPv6 typu „all-nodes multicast“, takže ju použijeme na testovanie všetkých uzlov IPv6 na odkaze. ("Broadcast" adresa je vlastne len špeciálne pomenovaná multicast adresa, čo je multicastová skupina, ktorá zahŕňa všetky uzly. Všimnite si, že napríklad bit "group" alebo multicast adresy je zapnutý v ethernetových vysielacích adresách na linkovej vrstve ).
Multicast IPv6 adresa všetkých uzlov pre kanál: ff02::1. ff označuje multicast IPv6 adresu. Ďalšia 0 je časť príznaku s nenastavenými bitmi.
Ďalšie 2 definuje oblasť skupiny multicast. Na rozdiel od multicastových adries IPv4 majú multicastové adresy IPv6 rozsah. Hodnota rozsahu označuje časť siete, cez ktorú je povolené posielať paket multicast. Keď paket dosiahne hranicu špecifikovaného rozsahu, paket sa musí zahodiť bez ohľadu na to, či je jeho pole Počet skokov nenulové. Samozrejme, ak počet skokov dosiahne nulu pred dosiahnutím špecifikovanej hranice skupiny multicast, je tiež okamžite resetovaný. Tu je úplný zoznam rozsahu IPv6 multicast.
Konečne, ::1 určuje skupinu multicast všetkých uzlov.
O adrese ff02::1 Treba poznamenať, že je to nejednoznačné. Na hostiteľovi IPv6 s viacerými rozhraniami, ako je napríklad smerovač alebo hostiteľ s viacerými adresami, adresa ff02::1 nie je tam nič, kde by ste mohli určiť, ktorému rozhraniu sa majú odosielať požiadavky na odozvu ICMPv6 alebo očakávať, že po ich príchode dostanete odpovede na odozvu ICMPv6. ff02::1 je platný a možno ho použiť na ktoromkoľvek z rozhraní a kanálov pripojených k uzlu s viacerými rozhraniami.
Takže keď pingujeme všetky uzly IPv6 na odkaz, musíme to nejako povedať aj obslužnému programu ping pre IPv6, ktoré rozhranie sa má použiť.
Definovanie rozhraní - možnosť príkazového riadka
Ako sme už videli, adresa multicast všetkých uzlov, ktorú chceme použiť, je - ff02::1 - neposkytuje žiadne informácie o tom, ktoré rozhranie má odosielať a prijímať ICMPv6 echo request a echo pakety odpovede.
Ako teda určíme rozhranie, ktoré sa má použiť pre viacsmerový adresný priestor alebo unicastový Link-Local adresný priestor?
Prvým a najzrejmejším spôsobom je poskytnúť ho ako parameter aplikácii, ktorú používame.
Pre užitočnosť ping poskytujeme cez opciu -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 ~]$Pomocou tohto príkazu ping pre všetky uzly sme dostali odpovede od 6 uzlov IPv6. Odpovede prišli z adries uzla Link-Local IPv6, počnúc predponou fe80::/10.
Že ping nepokračuje v odosielaní ICMPv6 echo requestov donekonečna, kým to neprerušíme, zvyčajne určíme počet paketov na odoslanie cez voľbu -c. To však tiež bráni príkazu ping prijať a zobraziť viac ako jednu odozvu ICMPv6 pri odosielaní žiadosti o odozvu multicast ICMPv6. Namiesto toho sme použili možnosť -w na určenie, že ping sa má dokončiť po 1 sekunde bez ohľadu na to, koľko žiadostí o odozvu ICMPv6 alebo odpovedí na odozvu bolo odoslaných alebo prijatých.
Ďalšia vec, ktorej treba venovať pozornosť, je (DUP!) výstup na druhú a ďalšie odpovede. Tieto pakety sú identifikované ako duplicitné odpovede, pretože majú rovnakú hodnotu sekvencie ICMP ako jednotlivé echo požiadavky ICMPv6, ktoré boli odoslané ako prvé. Objavujú sa, pretože požiadavka na odozvu multicast ICMPv6 vedie k viacerým individuálnym odpovediam unicast. Počet duplikátov je tiež uvedený v súhrne štatistík.
Definovanie rozhraní - ID zóny
Ďalším spôsobom, ako sprístupniť rozhranie na použitie, je ako súčasť parametra adresy IPv6.
Príklad toho môžeme vidieť vo výstupe ping, kde adresy odpovedajúcich hostiteľov IPv6 majú tiež príponu %enp3s2, napríklad:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msTáto metóda špecifikácie rozhraní je formálne opísaná v [RFC4007], "IPv6 Defined Address Architecture." Hoci sa zvyčajne nazývajú rozhranie operačného systému, v skutočnosti definujú niečo všeobecnejšie - „zónu“ alebo „rozsah“.
Dôvodom pre všeobecnejšie zóny alebo zóny rozsahu je, že ako je uvedené v [RFC4007], uzol IPv6 môže mať niekoľko rôznych rozhraní IPv6 pripojených k rovnakému kanálu. Tieto rozhrania sú členmi rovnakej zóny.
Malo by byť možné zoskupiť viacero rozhraní v rámci zóny pod operačným systémom; Momentálne neviem, či je to možné pod Linuxom alebo ako to urobiť.
Použitie prípony %<zone_id>, môžeme odstrániť možnosť príkazového riadku -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 ~]$Link-Local Address Responses
Z tohto multicastového pingu všetkých uzlov sme dostali celkovo 6 jedinečných odpovedí.
Tieto odpovede prišli z unicastových adries Link-Local IPv6 hostiteľov. Tu je napríklad prvá odpoveď:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msAdresy Unicast Link-Local IPv6 sa vyžadujú na všetkých rozhraniach s povoleným IPv6 [RFC4291], “IP Version 6 Addressing Architecture”. Dôvodom je, že IPv6 uzol má vždy automaticky unicast IPv6 adresu, ktorú môže aspoň použiť na komunikáciu s inými uzlami na svojich priamo pripojených linkách. To zahŕňa komunikáciu s aplikáciami na iných hostiteľoch prostredníctvom adries hostiteľov Link-Local.
To zjednodušuje návrh a implementáciu protokolov ako IPv6 Neighbor Discovery a OSPFv3. Umožňuje tiež aplikáciám koncových používateľov na hostiteľoch komunikovať cez kanál bez toho, aby na kanáli vyžadovali ďalšiu podpornú infraštruktúru IPv6. Priama komunikácia medzi pripojenými hostiteľmi IPv6 nevyžaduje pri pripojení smerovač IPv6 ani server DHCPv6.
Adresy Link-Local začínajú 10-bitovou predponou fe80, nasleduje 54 nulových bitov a potom 64-bitový identifikátor rozhrania (IID). Vo vyššie uvedenej prvej odpovedi 2392:6213:a15b:66ff je 64-bitové IID.
Viacnásobné vysielanie v slučke
V predvolenom nastavení sa pakety multicast vracajú interne do uzla, ktorý ich odoslal. Stáva sa to pri adresovaní IPv6 aj IPv4.
Dôvodom tohto predvoleného správania je, že pri odosielaní paketov multicast môže byť na samotnom odosielajúcom hostiteľovi spustená aj počúvajúca aplikácia lokálneho multicastu, ako aj niekde v sieti. Táto lokálna aplikácia musí tiež prijímať pakety multicast.
Túto lokálnu slučku multicast môžeme vidieť v našom výstupe 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!)
...Prvá a najrýchlejšia odozva (0,106 ms v porovnaní s 0,453 ms) pochádza z adresy Link-Local nakonfigurovanej na samotnom rozhraní enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Užitočnosť ping poskytuje spôsob potlačenia spätnej väzby lokálneho multicastu pomocou parametra -L. Ak pošleme ping pre všetky uzly multicast s týmto príznakom, odpovede sú obmedzené na vzdialené uzly. Nedostávame odpoveď z adresy Link-Local odosielajúceho rozhrania.
[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!)
...Pingujte na lokálne adresy odkazu
Ako by ste mohli uhádnuť, unicast Link-Local adresy samy o sebe tiež neposkytujú dostatok informácií na to, aby naznačili, ktoré rozhranie sa má použiť na ich dosiahnutie. Rovnako ako pri multicast pingu všetkých uzlov, musíme tiež špecifikovať rozhranie ako parameter príkazového riadku ping alebo ID zóny s adresou pri pingovaní na adresy Link-Local.
Tentoraz môžeme využiť -cobmedziť počet odoslaných a prijatých paketov a odpovedí ping, keďže vykonávame ping 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 ~]$Pingovať (všetky) ostatné adresy IPv6?
V tomto článku sme videli, ako pingovať všetky uzly IPv6 na kanáli pomocou adresy IPv6 multicast pre všetky uzly ff02::1. Tiež sme videli, ako určiť, ktoré rozhranie sa má použiť s adresou IPv6 multicast so všetkými uzlami, pretože samotná adresa nemôže poskytnúť tieto informácie. Použili sme buď možnosť príkazového riadku ping, alebo špecifikovať rozhranie pomocou prípony %<zone_id>.
Potom sme sa dozvedeli o adresách unicast Link-Local, čo sú adresy používané na odpovedanie na žiadosti o odozvu multicast ICMPv6 zo všetkých uzlov.
Videli sme tiež, ako sa multicastové pakety štandardne vracajú do odosielajúceho uzla a ako to v nástroji zakázať ping.
Nakoniec sme pomocou prípony odoslali príkaz ping na jednu adresu Link-Local %<zone_id>, keďže samotné adresy Link-Local tiež neposkytujú informácie o odchádzajúcom rozhraní.
Čo tak pingnúť všetky ostatné uzly a získať ich globálne unicast adresy (GUA) (to znamená ich verejné adresy na internete) alebo ich jedinečné lokálne unicast adresy (ULA)? Na to sa pozrieme v ďalšom blogovom príspevku.
To je všetko.
Viac o našom kurze sa dozviete na.
Zdroj: hab.com