Ostalo je još nekoliko dana do početka novog protoka po stopi od OTUS. S tim u vezi, željeli bismo podijeliti s vama prijevod korisnog materijala na ovu temu.
Niz postova na blogu o savjetima i trikovima za rješavanje problema IPv6 pinga (ICMPv6 Echo Request/Echo Reply)
Imajte na umu da koristim Linux (posebno Fedora 31), međutim, nadamo se da bi sintaksa ping komande za druge operativne sisteme trebala biti vrlo slična.
Pingirajte sve IPv6 čvorove na kanalu
Prvi i najjednostavniji savjet je da pingujete sve IPv6 čvorove na linku.
IPv6 koristi multicast adrese za sve vrste komunikacija jedan-prema-više. Ne postoje IPv6 adrese za emitiranje (ili emitiranje). Ovo razlikuje IPv6 od IPv4, gde postoji nekoliko tipova adresa za emitovanje, na primer, adresa „ograničenog emitovanja“ 255.255.255.255 [RFC1122].
Međutim, postoji "multicast" IPv6 adresa, tako da ćemo je koristiti za pingovanje svih IPv6 čvorova na linku. ("Broadcast" adresa je zapravo samo posebno nazvana multicast adresa, koja je multicast grupa koja uključuje sve čvorove. Imajte na umu da je, na primjer, bit "grupe" ili multicast adrese uključen u Ethernet broadcast adresama na sloju veze ).
Multicast IPv6 adresa svih čvorova za kanal: ff02::1. ff označava multicast IPv6 adresu. Sljedeća 0 je dio zastave s nepostavljenim bitovima.
dalje 2 definira područje višestruke grupe. Za razliku od multicast IPv4 adresa, multicast IPv6 adrese imaju opseg. Vrijednost opsega označava dio mreže preko kojeg je dozvoljeno prosljeđivanje višestrukog paketa. Jednom kada paket dostigne granicu specificiranog opsega, paket mora biti odbačen, bez obzira da li je njegovo polje Hop Count različito od nule. Naravno, ako broj skokova dostigne nulu prije nego što dostigne određenu granicu višestruke grupe, on se također odmah resetuje. Ovdje je kompletna lista IPv6 multicast opsega.
Na kraju, ::1 specificira multicast grupu sa svim čvorovima.
O adresi ff02::1 Treba napomenuti da je dvosmislen. Na IPv6 hostu sa više sučelja, kao što je ruter ili višedomni host, adresa ff02::1 ne postoji ništa gdje možete odrediti kojem interfejsu želite poslati ICMPv6 eho zahtjeve ili očekivati da ćete primiti ICMPv6 eho odgovore kada stignu. ff02::1 je važeći i može se koristiti na bilo kojem od interfejsa i kanala koji su priključeni na čvor sa više interfejsa.
Dakle, kada pingujemo sve IPv6 čvorove na linku, moramo nekako reći i pomoćnom programu ping za IPv6, koji interfejs koristiti.
Definiranje interfejsa - opcija komandne linije
Kao što smo već vidjeli, multicast adresa svih čvorova koju želimo koristiti je − ff02::1 - ne daje nikakve informacije o tome koji interfejs treba poslati i primiti ICMPv6 pakete eho zahtjeva i eho odgovora.
Dakle, kako da navedemo interfejs koji će se koristiti za multicast adresni prostor ili unicast Link-Local adresni prostor?
Prvi i najočitiji način je da ga navedemo kao parametar aplikaciji koju koristimo.
Za korisnost ping mi to pružamo kroz opciju -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 ~]$Koristeći ovaj multicast ping svih čvorova, dobili smo odgovore od 6 IPv6 čvorova. Odgovori su došli sa Link-Local IPv6 adresa čvora, počevši od prefiksa fe80::/10.
da ping ne nastavlja sa slanjem ICMPv6 eho zahtjeva na neodređeno vrijeme dok ga ne prekinemo, obično specificiramo broj paketa za slanje preko -c opcije. Međutim, ovo također sprječava ping da prihvati i prikaže više od jednog ICMPv6 eho odgovora prilikom slanja multicast ICMPv6 eho zahtjeva. Umjesto toga, koristili smo opciju -w da navedemo da se ping završi nakon 1 sekunde, bez obzira na to koliko je ICMPv6 eho zahtjeva ili eho odgovora poslano ili primljeno.
Još jedna stvar na koju treba obratiti pažnju je (DUP!) izlaz na drugi i naredni odgovori. Ovi paketi su identificirani kao dupli odgovori jer imaju istu vrijednost ICMP sekvence kao pojedinačni ICMPv6 eho zahtjevi koji su poslati na prvom mjestu. Pojavljuju se zato što ICMPv6 multicast echo zahtjev rezultira višestrukim pojedinačnim unicast odgovorima. Broj duplikata je također naveden u statističkom sažetku.
Definiranje interfejsa - ID zone
Drugi način da se sučelje izloži za upotrebu je kao dio parametra IPv6 adrese.
Primjer ovoga možemo vidjeti u ping izlazu, gdje adrese IPv6 hostova koji odgovaraju također imaju sufiks %enp3s2, na primjer:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msOva metoda specificiranja interfejsa je formalno opisana u [RFC4007], "IPv6 definisana adresna arhitektura." Iako se obično nazivaju interfejsom operativnog sistema, oni zapravo definišu nešto opštije — „zonu“ ili „opseg“.
Razlog za postojanje opštijih zona ili zona opsega je taj što, kao što je spomenuto u [RFC4007], IPv6 čvor može imati nekoliko različitih IPv6 interfejsa povezanih na isti kanal. Ova sučelja su članovi iste zone.
Trebalo bi biti moguće grupisati više interfejsa unutar zone pod operativnim sistemom; Trenutno ne znam da li je to moguće pod Linuxom ili kako to učiniti.
Korištenje sufiksa %<zone_id>, možemo ukloniti opciju komandne linije -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
Od ovog multicast pinga svih čvorova dobili smo ukupno 6 jedinstvenih odgovora.
Ovi odgovori su došli sa jednokrevetnih Link-Local IPv6 host adresa. Na primjer, evo prvog odgovora:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msUnicast Link-Lokalne IPv6 adrese su potrebne na svim IPv6-omogućenim sučeljima [RFC4291], “IP Verzija 6 Arhitektura adresiranja”. Razlog za to je taj što IPv6 čvor uvijek automatski ima jednosmjernu IPv6 adresu, koju barem može koristiti za komunikaciju s drugim čvorovima na svojim direktno povezanim vezama. Ovo uključuje komunikaciju sa aplikacijama na drugim hostovima putem Link-Local host adresa.
Ovo pojednostavljuje dizajn i implementaciju protokola kao što su IPv6 Neighbor Discovery i OSPFv3. Takođe omogućava aplikacijama krajnjih korisnika na hostovima da komuniciraju preko kanala bez potrebe za bilo kojom drugom podrškom IPv6 infrastrukturom na kanalu. Direktna komunikacija između povezanih IPv6 hostova ne zahtijeva IPv6 ruter ili DHCPv6 server na vezi.
Link-Local adrese počinju sa 10-bitnim prefiksom fe80, nakon čega slijedi 54 nula bita i zatim 64-bitni identifikator interfejsa (IID). U gornjem prvom odgovoru 2392:6213:a15b:66ff je 64-bitni IID.
Looped Multicast
Podrazumevano, multicast paketi se vraćaju interno čvoru koji ih je poslao. Ovo se dešava i za IPv6 i za IPv4 adresiranje.
Razlog za ovo zadano ponašanje je taj što kada se šalju multicast paketi, može postojati i lokalna multicast aplikacija koja sluša na samom hostu koji šalje, kao i negdje na mreži. Ova lokalna aplikacija također mora primati multicast pakete.
Ovu multicast lokalnu petlju možemo vidjeti u našem ping izlazu:
[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 i najbrži odgovor (0,106 ms u poređenju sa 0,453 ms) dolazi od Link-Local adrese konfigurirane na samom interfejsu enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Utility ping pruža način za suzbijanje lokalne multicast povratne informacije pomoću parametra -L. Ako pošaljemo multicast ping za sve čvorove sa ovom zastavicom, odgovori su ograničeni na udaljene čvorove. Ne primamo odgovor od Link-Local adrese interfejsa za slanje.
[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-lokalne adrese
Kao što možete pretpostaviti, unicast Link-Local adrese same po sebi takođe ne daju dovoljno informacija da bi se naznačilo koji interfejs treba koristiti da do njih dođe. Kao i kod multicast pinga svih čvorova, također moramo navesti sučelje kao parametar komandne linije ping ili ID zone sa adresom prilikom pingovanja Link-Local adresa.
Ovaj put možemo iskoristiti -cda ograničite broj paketa i odgovora poslatih i primljenih ping, pošto izvodimo 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 ~]$Pingovati (sve) druge IPv6 adrese?
U ovom članku smo vidjeli kako pingovati sve IPv6 čvorove na kanalu koristeći multicast IPv6 adresu svih čvorova ff02::1. Također smo vidjeli kako odrediti koji interfejs koristiti sa multicast IPv6 adresom svih čvorova, budući da sama adresa ne može pružiti ove informacije. Koristili smo ili opciju komandne linije ping, ili specificirao sučelje koristeći sufiks %<zone_id>.
Zatim smo naučili o unicast Link-Local adresama, koje su adrese koje se koriste za odgovor na multicast ICMPv6 echo zahtjeve svih čvorova.
Također smo vidjeli kako se multicast paketi po defaultu vraćaju čvoru za slanje i kako to onemogućiti za pomoćni program ping.
Konačno, pingovali smo jednu Link-Local adresu koristeći sufiks %<zone_id>, budući da same Link-Local adrese takođe ne daju informacije o odlaznom interfejsu.
Dakle, šta je sa pingom svih ostalih čvorova i dobijanjem njihovih globalnih unicast adresa (GUA) (tj. njihovih javnih adresa na Internetu) ili njihovih jedinstvenih lokalnih unicast adresa (ULA)? Ovo ćemo pogledati u sljedećem blog postu.
To je sve.
Više o našem kursu možete saznati na.
izvor: www.habr.com