Iki naujo srauto pradžios liko kelios dienos iš OTUS. Šiuo atžvilgiu norėtume pasidalinti su jumis naudingos medžiagos šia tema vertimu.
Tinklaraščio įrašų serija apie patarimus ir gudrybes, kaip pašalinti IPv6 ping problemas (ICMPv6 Echo Request / Echo Reply)
Atkreipkite dėmesį, kad aš naudoju Linux (ypač Fedora 31), tačiau kitų operacinių sistemų ping komandos sintaksė turėtų būti labai panaši.
Ping visi IPv6 mazgai kanale
Pirmasis ir paprasčiausias patarimas yra ping visi IPv6 mazgai, esantys nuorodoje.
IPv6 naudoja daugialypės siuntimo adresus visų tipų „vienas su daugeliu“ ryšiui. Nėra transliuojamų (arba transliuojamų) IPv6 adresų. Tai išskiria IPv6 nuo IPv4, kur yra kelių tipų transliavimo adresai, pavyzdžiui, „riboto transliavimo“ adresas 255.255.255.255 [RFC1122].
Tačiau yra „visų mazgų daugialypės siuntimo“ IPv6 adresas, todėl jį naudosime, kad susisiektume su visais nuorodos IPv6 mazgais. („Transliavimo“ adresas iš tikrųjų yra tik specialiai pavadintas daugialypės terpės adresas, kuris yra daugialypės siuntimo grupė, apimanti visus mazgus. Atminkite, kad, pavyzdžiui, „grupės“ arba daugialypės siuntimo adreso bitas yra įjungtas Ethernet transliacijos adresuose nuorodų sluoksnyje. ).
Visų mazgų daugialypės siuntimo IPv6 adresas kanalui: ff02::1. ff žymi multicast IPv6 adresą. Kitas 0 yra vėliavos dalis su nenustatytais bitais.
Toliau 2 apibrėžia daugialypės siuntimo grupės sritį. Skirtingai nuo daugialypės siuntimo IPv4 adresų, daugialypės siuntimo IPv6 adresai turi taikymo sritį. Apimties reikšmė nurodo tinklo dalį, per kurią leidžiama persiųsti daugialypės terpės paketą. Kai paketas pasiekia nurodytos apimties ribą, paketas turi būti atmestas, neatsižvelgiant į tai, ar jo Šuolių skaičiaus laukas nėra nulis. Žinoma, jei šuolių skaičius pasiekia nulį prieš pasiekdamas nurodytą daugialypės terpės grupės ribą, jis taip pat nedelsiant atstatomas. Čia yra visas IPv6 daugialypės siuntimo apimties sąrašas.
Galiausiai, ::1 nurodo visų mazgų daugialypės siuntimo grupę.
Apie adresą ff02::1 Reikėtų pažymėti, kad jis yra dviprasmiškas. IPv6 pagrindiniame kompiuteryje su keliomis sąsajomis, pvz., maršruto parinktuvu arba daugiafunkciu kompiuteriu, adresas ff02::1 nėra nieko, kur galėtumėte nurodyti, kuriai sąsajai siųsti ICMPv6 echo užklausas arba tikėtis gauti ICMPv6 aido atsakymus, kai jie atvyks. ff02::1 galioja ir gali būti naudojamas bet kurioje iš sąsajų ir kanalų, prijungtų prie kelių sąsajų mazgo.
Taigi, kai sujungiame visus nuorodos IPv6 mazgus, turime kažkaip pranešti ir paslaugų programai ping IPv6, kurią sąsają naudoti.
Sąsajų apibrėžimas – komandų eilutės parinktis
Kaip jau matėme, visų mazgų multicast adresas, kurį norime naudoti, yra − ff02::1 - nepateikia jokios informacijos apie tai, kokia sąsaja siųsti ir gauti ICMPv6 echo užklausų ir echo atsakymo paketus.
Taigi, kaip nurodyti sąsają, kuri bus naudojama daugialypės siuntimo adresų erdvei arba unicast Link-Local adresų erdvei?
Pirmasis ir akivaizdžiausias būdas yra pateikti jį kaip mūsų naudojamos programos parametrą.
Dėl naudingumo ping mes suteikiame jį pasirinkdami -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 ~]$Naudodami šį visų mazgų multicast ping, gavome atsakymus iš 6 IPv6 mazgų. Atsakymai buvo gauti iš Link-Local IPv6 mazgų adresų, pradedant priešdėliu fe80::/10.
Kad ping nesiunčia ICMPv6 echo užklausų neribotą laiką, kol mes jo nenutraukiame, paprastai nurodome siunčiamų paketų skaičių naudodami parinktį -c. Tačiau tai taip pat neleidžia ping priimti ir rodyti daugiau nei vieno ICMPv6 aido atsakymo siunčiant daugialypės siuntimo ICMPv6 aido užklausą. Vietoj to, naudojome parinktį -w, norėdami nurodyti, kad ping turi būti baigtas po 1 sekundės, nesvarbu, kiek ICMPv6 aido užklausų ar atsakymų buvo išsiųsta ar gauta.
Kitas dalykas, į kurį reikia atkreipti dėmesį, yra (DUP!) išvestis ant antrojo ir tolesnių atsakymų. Šie paketai identifikuojami kaip pasikartojantys atsakymai, nes jie turi tą pačią ICMP sekos reikšmę kaip ir atskiros ICMPv6 aido užklausos, kurios buvo išsiųstos pirmiausia. Jie atsiranda dėl to, kad ICMPv6 daugialypės siuntimo aido užklausa sukelia kelis individualius unicast atsakymus. Dublikatų skaičius nurodomas ir statistikos suvestinėje.
Sąsajų apibrėžimas – zonos ID
Kitas būdas atskleisti sąsają naudoti yra IPv6 adreso parametro dalis.
To pavyzdį galime pamatyti ping išvestyje, kur atsakančių IPv6 pagrindinių kompiuterių adresai taip pat turi galūnę %enp3s2, pavyzdžiui:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msŠis sąsajų nustatymo metodas oficialiai aprašytas [RFC4007], „IPv6 apibrėžta adresų architektūra“. Nors jie paprastai vadinami operacinės sistemos sąsaja, jie iš tikrųjų apibrėžia kažką bendresnio – „zoną“ arba „apimtį“.
Bendresnių zonų arba taikymo srities zonų priežastis yra ta, kad, kaip minėta [RFC4007], IPv6 mazgas gali turėti kelias skirtingas IPv6 sąsajas, prijungtas prie to paties kanalo. Šios sąsajos yra tos pačios zonos nariai.
Turėtų būti įmanoma sugrupuoti kelias sąsajas vienoje operacinės sistemos zonoje; Šiuo metu nežinau, ar tai įmanoma naudojant Linux ir kaip tai padaryti.
Naudojant priesagą %<zone_id>, galime pašalinti komandinės eilutės parinktį -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 ~]$Nuoroda – vietinio adreso atsakymai
Iš šio visų mazgų multicast ping iš viso gavome 6 unikalius atsakymus.
Šie atsakymai buvo gauti iš unicast Link-Local IPv6 pagrindinio kompiuterio adresų. Pavyzdžiui, čia yra pirmasis atsakymas:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms„Unicast Link-Local“ IPv6 adresai reikalingi visose sąsajose, kuriose įgalintas IPv6 [RFC4291], „IP 6 versijos adresų architektūra“. Taip yra dėl to, kad IPv6 mazgas visada automatiškai turi unikalų IPv6 adresą, kurį jis bent jau gali naudoti bendraudamas su kitais mazgais tiesiogiai prijungtuose saituose. Tai apima ryšį su programomis kituose pagrindiniuose kompiuteriuose naudojant „Link-Local“ pagrindinio kompiuterio adresus.
Tai supaprastina tokių protokolų kaip IPv6 Neighbor Discovery ir OSPFv3 projektavimą ir įgyvendinimą. Tai taip pat leidžia galutinio vartotojo programoms pagrindiniuose kompiuteriuose bendrauti per kanalą nereikalaujant jokios kitos palaikomos IPv6 infrastruktūros kanale. Tiesioginiam ryšiui tarp prijungtų IPv6 pagrindinių kompiuterių nereikia IPv6 maršrutizatoriaus arba DHCPv6 serverio.
Link-Local adresai prasideda 10 bitų priešdėliu fe80, po kurio seka 54 nuliniai bitai ir 64 bitų sąsajos identifikatorius (IID). Aukščiau pateiktame pirmame atsakyme 2392:6213:a15b:66ff yra 64 bitų IID.
Daugialypė transliacija
Pagal numatytuosius nustatymus daugialypės terpės paketai grąžinami juos siuntusiam mazgui. Tai atsitinka tiek IPv6, tiek IPv4 adresams.
Tokios numatytosios elgsenos priežastis yra ta, kad kai siunčiami daugialypės terpės paketai, taip pat gali būti klausymosi vietinė daugialypės terpės programa, kuri veikia pačiame siunčiančiame pagrindiniame kompiuteryje, taip pat kažkur tinkle. Ši vietinė programa taip pat turi gauti daugialypės siuntimo paketus.
Mes matome šią daugialypės siuntimo vietinę kilpą mūsų ping išvestyje:
[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!)
...Pirmasis ir greičiausias atsakas (0,106 ms, palyginti su 0,453 ms) gaunamas iš „Link-Local“ adreso, sukonfigūruoto pačioje sąsajoje enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Naudingumas ping suteikia galimybę slopinti vietinį daugialypės terpės grįžtamąjį ryšį naudojant parametrą -L. Jei siunčiame visų mazgų daugialypės siuntimo ping su šia vėliava, atsakymai apsiriboja nuotoliniais mazgais. Negauname atsakymo iš siuntimo sąsajos „Link-Local“ adreso.
[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 – vietiniai adresai
Kaip jau galima spėti, vieni perduodami „Link-Local“ adresai taip pat nepateikia pakankamai informacijos, kad būtų nurodyta, kurią sąsają naudoti norint juos pasiekti. Kaip ir naudojant visų mazgų daugialypės siuntimo ping, sąsają taip pat turime nurodyti kaip komandinės eilutės parametrą ping arba zonos ID su adresu, kai pinguojama Link-Local adresus.
Šį kartą galime pasinaudoti -capriboti siunčiamų ir gaunamų paketų ir atsakymų skaičių ping, nes atliekame 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 ~]$Ping (visi) kiti IPv6 adresai?
Šiame straipsnyje mes matėme, kaip siųsti ping visus IPv6 mazgus kanale naudojant visų mazgų daugialypės siuntimo IPv6 adresą ff02::1. Taip pat matėme, kaip nurodyti, kurią sąsają naudoti su visų mazgų daugialypės siuntimo IPv6 adresu, nes pats adresas negali pateikti šios informacijos. Mes naudojome arba komandinės eilutės parinktį ping, arba nurodė sąsają naudodami galūnę %<zone_id>.
Tada sužinojome apie unicast Link-Local adresus, kurie yra adresai, naudojami atsakant į visų mazgų daugialypės siuntimo ICMPv6 aido užklausas.
Taip pat matėme, kaip multicast paketai pagal numatytuosius nustatymus grąžinami į siunčiantį mazgą ir kaip tai išjungti programai ping.
Galiausiai sujungėme vieną „Link-Local“ adresą naudodami galūnę %<zone_id>, nes patys Link-Local adresai taip pat neteikia informacijos apie išeinančią sąsają.
Taigi, ką daryti su visų kitų mazgų ping ir gauti jų visuotinius unicast adresus (GUA) (ty viešuosius adresus internete) arba unikalius vietinius unicast adresus (ULA)? Tai panagrinėsime kitame tinklaraščio įraše.
Tai viskas.
Daugiau apie mūsų kursą galite sužinoti adresu.
Šaltinis: www.habr.com