Še nekaj dni je ostalo do začetka novega toka po stopnji od OTUS. V zvezi s tem bi radi z vami delili prevod uporabnega gradiva na to temo.
Niz objav v spletnem dnevniku o nasvetih in trikih za odpravljanje težav s pingom IPv6 (ICMPv6 Echo Request/Echo Reply)
Upoštevajte, da uporabljam Linux (zlasti Fedora 31), vendar bi morala biti sintaksa ukaza ping za druge operacijske sisteme zelo podobna.
Ping vsa vozlišča IPv6 na kanalu
Prvi in najpreprostejši nasvet je pinganje vseh vozlišč IPv6 na povezavi.
IPv6 uporablja večvrstne naslove za vse vrste komunikacij eden proti več. Ni oddajnih (ali oddajnih) naslovov IPv6. To razlikuje IPv6 od IPv4, kjer obstaja več vrst oddajnih naslovov, na primer naslov »omejeno oddajanje« 255.255.255.255 [RFC1122].
Vendar pa obstaja naslov IPv6 za »multicast za vsa vozlišča«, zato ga bomo uporabili za pinganje vseh vozlišč IPv6 na povezavi. ("Broadcast" naslov je pravzaprav samo posebej imenovan multicast naslov, ki je multicast skupina, ki vključuje vsa vozlišča. Upoštevajte, da je na primer "group" ali multicast naslovni bit vklopljen v Ethernet broadcast naslovih na ravni povezave ).
Večkratni naslov IPv6 za vsa vozlišča za kanal: ff02::1. ff označuje multicast naslov IPv6. Naslednja 0 je del zastavice z nenastavljenimi biti.
Več 2 določa območje multicast skupine. Za razliko od večvrstnih naslovov IPv4 imajo večvrstni naslovi IPv6 obseg. Vrednost obsega označuje del omrežja, prek katerega je dovoljeno posredovati paket multicast. Ko paket doseže mejo podanega obsega, ga je treba zavreči, ne glede na to, ali je njegovo polje Hop Count različno od nič. Seveda se takoj ponastavi, če število skokov doseže nič, preden doseže določeno mejo skupine multicast. Tukaj je celoten seznam IPv6 multicast obsega.
Končno, ::1 določa multicast skupino z vsemi vozlišči.
O naslovu ff02::1 Treba je opozoriti, da je dvoumen. Na gostitelju IPv6 z več vmesniki, kot je usmerjevalnik ali večdomni gostitelj, naslov ff02::1 ni ničesar, kjer bi lahko določili, kateremu vmesniku želite poslati odmevne zahteve ICMPv6, ali pričakovati, da boste prejeli odmevne odgovore ICMPv6, ko bodo prispeli. ff02::1 je veljaven in se lahko uporablja na katerem koli od vmesnikov in kanalov, priključenih na večvmesniško vozlišče.
Torej, ko pingamo vsa vozlišča IPv6 na povezavi, moramo nekako sporočiti tudi pomožnemu programu ping za IPv6, kateri vmesnik uporabiti.
Definiranje vmesnikov – možnost ukazne vrstice
Kot smo že videli, je multicast naslov za vsa vozlišča, ki ga želimo uporabiti, − ff02::1 - ne zagotavlja nobenih informacij o tem, kateri vmesnik za pošiljanje in prejemanje ICMPv6 echo request in echo reply paketov.
Torej, kako določimo vmesnik, ki bo uporabljen za naslovni prostor za večvrstno oddajanje ali naslovni prostor za lokalno oddajanje povezav?
Prvi in najbolj očiten način je, da ga zagotovimo kot parameter aplikaciji, ki jo uporabljamo.
Za uporabnost ping nudimo preko opcije -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 ~]$Z uporabo tega multicast pinga za vsa vozlišča smo prejeli odgovore od 6 vozlišč IPv6. Odzivi so prišli z naslovov vozlišč IPv6 lokalne povezave, ki se začnejo s predpono fe80::/10.
To ping ne nadaljuje s pošiljanjem odmevnih zahtev ICMPv6 v nedogled, dokler ga ne prekinemo, običajno določimo število paketov za pošiljanje prek možnosti -c. Vendar to prav tako preprečuje, da bi ping sprejel in prikazal več kot en odmevni odgovor ICMPv6, ko pošilja zahtevo za odmev multicast ICMPv6. Namesto tega smo uporabili možnost -w, da določimo, da se mora ping zaključiti po 1 sekundi, ne glede na to, koliko ICMPv6 echo zahtev ali echo odgovorov je bilo poslanih ali prejetih.
Druga stvar, na katero morate biti pozorni, je (DUP!) izpis pri drugem in naslednjih odgovorih. Ti paketi so identificirani kot podvojeni odgovori, ker imajo enako vrednost zaporedja ICMP kot posamezne zahteve za odmev ICMPv6, ki so bile najprej poslane. Pojavijo se, ker zahteva ICMPv6 multicast echo povzroči več posameznih unicast odgovorov. Število dvojnikov je navedeno tudi v povzetku statistike.
Definiranje vmesnikov - Zone ID
Drug način za izpostavitev vmesnika za uporabo je kot del parametra naslova IPv6.
Primer tega lahko vidimo v izhodu ping, kjer imajo naslovi odzivnih gostiteljev IPv6 tudi pripono %enp3s2, na primer:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msTa metoda določanja vmesnikov je uradno opisana v [RFC4007], "IPv6 Defined Address Architecture." Čeprav se običajno imenujejo vmesnik operacijskega sistema, dejansko definirajo nekaj bolj splošnega – »območje« ali »obseg«.
Razlog za bolj splošna območja ali območja obsega je, kot je omenjeno v [RFC4007], da ima lahko vozlišče IPv6 več različnih vmesnikov IPv6, povezanih z istim kanalom. Ti vmesniki so člani iste cone.
Moralo bi biti mogoče združiti več vmesnikov znotraj območja pod operacijskim sistemom; Trenutno ne vem, ali je to mogoče pod Linuxom ali kako to narediti.
Uporaba pripone %<zone_id>, lahko odstranimo možnost ukazne vrstice -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
Iz tega multicast pinga za vsa vozlišča smo prejeli skupno 6 edinstvenih odgovorov.
Ti odgovori so prišli z naslovov gostiteljev IPv6 z enosmerno lokalno povezavo. Na primer, tukaj je prvi odgovor:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msUnicast Link-Local IPv6 naslovi so potrebni na vseh vmesnikih, ki podpirajo IPv6 [RFC4291], “Različica IP 6 Addressing Architecture”. Razlog za to je, da ima vozlišče IPv6 vedno samodejno naslov IPv6 za enoodposlano uporabo, ki ga lahko uporablja vsaj za komunikacijo z drugimi vozlišči na svojih neposredno povezanih povezavah. To vključuje komunikacijo z aplikacijami na drugih gostiteljih prek naslovov gostiteljev Link-Local.
To poenostavi načrtovanje in implementacijo protokolov, kot sta IPv6 Neighbor Discovery in OSPFv3. Omogoča tudi, da aplikacije končnega uporabnika na gostiteljih komunicirajo prek kanala, ne da bi na kanalu potrebovali katero koli drugo podporno infrastrukturo IPv6. Neposredna komunikacija med povezanimi gostitelji IPv6 ne zahteva usmerjevalnika IPv6 ali strežnika DHCPv6 v povezavi.
Link-Local naslovi se začnejo z 10-bitno predpono fe80, ki mu sledi 54 ničelnih bitov in nato 64-bitni identifikator vmesnika (IID). V zgornjem prvem odgovoru 2392:6213:a15b:66ff je 64-bitni IID.
Looped Multicast
Privzeto se multicast paketi interno vrnejo vozlišču, ki jih je poslalo. To se zgodi pri naslavljanju IPv6 in IPv4.
Razlog za to privzeto vedenje je, da lahko ob pošiljanju večvrstnih paketov obstaja tudi poslušajoča lokalna večvrstna aplikacija, ki se izvaja na samem gostitelju pošiljatelju, pa tudi nekje v omrežju. Ta lokalna aplikacija mora prejemati tudi pakete za večvrstno oddajanje.
To multicast lokalno zanko lahko vidimo v našem izhodu 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!)
...Prvi in najhitrejši odziv (0,106 ms v primerjavi z 0,453 ms) prihaja iz naslova Link-Local, konfiguriranega na samem vmesniku enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Uporabnost ping ponuja način za zatiranje lokalnih večvrstnih povratnih informacij s parametrom -L. Če pošljemo multicast ping za vsa vozlišča s to zastavico, so odgovori omejeni na oddaljena vozlišča. Ne prejmemo odgovora z naslova Link-Local vmesnika za pošiljanje.
[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 – lokalni naslovi
Kot morda ugibate, tudi naslovi unicast Link-Local sami po sebi ne zagotavljajo dovolj informacij, ki bi pokazale, kateri vmesnik uporabiti za doseganje. Tako kot pri multicast pingu za vsa vozlišča moramo tudi vmesnik določiti kot parameter ukazne vrstice ping ali ID območja z naslovom pri pinganju naslovov Link-Local.
Ta čas lahko uporabimo -cza omejitev števila poslanih in prejetih paketov ter odgovorov ping, saj izvajamo 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 (vse) druge naslove IPv6?
V tem članku smo videli, kako pingati vsa vozlišča IPv6 na kanalu z uporabo naslova IPv6 za večvrstno oddajanje vseh vozlišč ff02::1. Videli smo tudi, kako določiti, kateri vmesnik uporabiti z naslovom IPv6 za večvrstno oddajanje vseh vozlišč, saj naslov sam ne more zagotoviti teh informacij. Uporabili smo možnost ukazne vrstice ping, ali določil vmesnik s pripono %<zone_id>.
Potem smo izvedeli za naslove unicast Link-Local, ki so naslovi, ki se uporabljajo za odziv na zahteve za odmev ICMPv6 za večvrstno oddajanje vseh vozlišč.
Videli smo tudi, kako se multicast paketi privzeto vrnejo pošiljatelju in kako to onemogočiti za pripomoček ping.
Končno smo pingali en naslov Link-Local z uporabo pripone %<zone_id>, saj tudi sami naslovi Link-Local ne zagotavljajo informacij o odhodnem vmesniku.
Kaj pa ping za vsa druga vozlišča in pridobitev njihovih globalnih naslovov enoposteljnih (GUA) (to je njihovih javnih naslovov v internetu) ali njihovih edinstvenih lokalnih enonastavljenih naslovov (ULA)? To si bomo ogledali v naslednji objavi v spletnem dnevniku.
To je vse.
Več o našem tečaju lahko izveste na.
Vir: www.habr.com