Pingajte sve IPv6 čvorove na kanalu

Ostalo je nekoliko dana do početka novog protoka po stopi "Mrežni inženjer" od OTUS-a. U tom smislu, željeli bismo s vama podijeliti prijevod korisnog materijala na tu temu.

Pingajte sve IPv6 čvorove na kanalu

Niz postova na blogu o savjetima i trikovima za rješavanje problema s IPv6 pingom (ICMPv6 Echo Request/Echo Reply)

Imajte na umu da koristim Linux (točnije Fedora 31), no nadam se da bi sintaksa naredbe ping za druge operativne sustave trebala biti vrlo slična.

Pingajte sve IPv6 čvorove na kanalu

Prvi i najjednostavniji savjet je pingati sve IPv6 čvorove na vezi.

IPv6 koristi multicast adrese za sve vrste komunikacija jedan prema više. Nema emitiranih (ili emitiranih) IPv6 adresa. Ovo razlikuje IPv6 od IPv4, gdje postoji nekoliko vrsta adresa za emitiranje, na primjer, adresa "ograničenog emitiranja" 255.255.255.255 [RFC1122].

Međutim, postoji IPv6 adresa "multicast za sve čvorove", pa ćemo je koristiti za ping svih IPv6 čvorova na vezi. ("Broadcast" adresa je zapravo samo posebno imenovana multicast adresa, koja je multicast grupa koja uključuje sve čvorove. Imajte na umu da je, na primjer, bit "group" ili multicast adrese uključen u Ethernet adresama emitiranja na sloju veze ).

Multicast IPv6 adresa svih čvorova za kanal: ff02::1. ff označava multicast IPv6 adresu. Sljedeća 0 je dio oznake s nepostavljenim bitovima.

Dalje 2 definira područje multicast grupe. Za razliku od multicast IPv4 adresa, multicast IPv6 adrese imaju opseg. Vrijednost opsega označava dio mreže preko kojeg je dopušteno prosljeđivanje multicast paketa. Jednom kada paket dosegne granicu navedenog opsega, paket se mora odbaciti, bez obzira na to je li njegovo polje Broj skokova različito od nule. Naravno, ako broj skokova dosegne nulu prije nego što dosegne specificiranu granicu multicast grupe, također se odmah poništava. Ovdje je potpuni popis IPv6 multicast opsega.

Konačno, ::1 specificira multicast grupu sa svim čvorovima.

O adresi ff02::1 Treba napomenuti da je dvosmislen. Na IPv6 hostu s više sučelja, kao što je usmjerivač ili multihomed host, adresa ff02::1 ne postoji ništa gdje možete odrediti kojem sučelju poslati ICMPv6 echo zahtjeve ili očekivati ​​da ćete primiti ICMPv6 echo odgovore kada stignu. ff02::1 je valjan i može se koristiti na bilo kojem od sučelja i kanala priključenih na čvor s više sučelja.

Dakle, kada pingamo sve IPv6 čvorove na vezi, moramo nekako reći i uslužnom programu ping za IPv6, koje sučelje koristiti.

Definiranje sučelja - opcija naredbenog retka

Kao što smo već vidjeli, multicast adresa svih čvorova koju želimo koristiti je − ff02::1 - ne pruža nikakve informacije o tome koje sučelje slati i primati ICMPv6 echo zahtjev i pakete echo odgovora.

Dakle, kako ćemo odrediti sučelje koje će se koristiti za multicast adresni prostor ili unicast Link-Local adresni prostor?

Prvi i najočitiji način je dati ga kao parametar aplikaciji koju koristimo.

Za korisnost ping pružamo ga 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 za sve čvorove, primili smo odgovore od 6 IPv6 čvorova. Odgovori su dolazili s adresa IPv6 čvorova lokalne veze, počevši od prefiksa fe80::/10.

Da ping ne nastavlja slati ICMPv6 echo zahtjeve na neodređeno vrijeme dok ga ne prekinemo, obično odredimo broj paketa za slanje putem -c opcije. Međutim, to također sprječava ping da prihvati i prikaže više od jednog ICMPv6 echo odgovora prilikom slanja multicast ICMPv6 echo zahtjeva. Umjesto toga, upotrijebili smo opciju -w da navedemo da se ping treba završiti nakon 1 sekunde, bez obzira na to koliko je ICMPv6 echo zahtjeva ili echo odgovora poslano ili primljeno.

Još jedna stvar na koju treba obratiti pozornost je (DUP!) izlaz na drugom i sljedećim odgovorima. Ti se paketi identificiraju kao dvostruki odgovori jer imaju istu vrijednost ICMP sekvence kao pojedinačni ICMPv6 echo zahtjevi koji su prvotno poslani. Pojavljuju se jer ICMPv6 multicast echo zahtjev rezultira višestrukim pojedinačnim unicast odgovorima. Broj duplikata također je naznačen u sažetku statistike.

Definiranje sučelja - ID zone

Drugi način izlaganja sučelja za korištenje je dio parametra IPv6 adrese.

Možemo vidjeti primjer ovoga 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 ms

Ova metoda određivanja sučelja službeno je opisana u [RFC4007], "IPv6 definirana adresa arhitekture." Iako se obično nazivaju sučeljem operativnog sustava, oni zapravo definiraju nešto općenitije - "zonu" ili "opseg".

Razlog za postojanje općenitijih zona ili zona opsega je taj što, kao što je spomenuto u [RFC4007], IPv6 čvor može imati nekoliko različitih IPv6 sučelja povezanih na isti kanal. Ova su sučelja članovi iste zone.

Trebalo bi biti moguće grupirati više sučelja unutar zone pod operativnim sustavom; Trenutačno ne znam je li to moguće pod Linuxom ili kako to učiniti.

Korištenje sufiksa %<zone_id>, možemo ukloniti opciju naredbenog retka -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 ~]$

Odgovori vezane lokalne adrese

Od ovog multicast pinga za sve čvorove primili smo ukupno 6 jedinstvenih odgovora.

Ovi su odgovori došli s unicast 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 ms

Unicast Link-Local IPv6 adrese potrebne su na svim IPv6-omogućenim sučeljima [RFC4291], “IP verzija 6 adresar arhitekture”. Razlog za to je što IPv6 čvor uvijek automatski ima unicast IPv6 adresu, koju barem može koristiti za komunikaciju s drugim čvorovima na svojim izravno povezanim vezama. To uključuje komunikaciju s aplikacijama na drugim hostovima putem Link-Local host adresa.

To pojednostavljuje dizajn i implementaciju protokola kao što su IPv6 Neighbor Discovery i OSPFv3. Također omogućuje aplikacijama krajnjih korisnika na hostovima da komuniciraju preko kanala bez potrebe za bilo kojom drugom pratećom IPv6 infrastrukturom na kanalu. Izravna komunikacija između povezanih IPv6 hostova ne zahtijeva IPv6 usmjerivač ili DHCPv6 poslužitelj na vezi.

Link-Local adrese počinju 10-bitnim prefiksom fe80, zatim 54 nula bita i zatim 64-bitni identifikator sučelja (IID). U gornjem prvom odgovoru 2392:6213:a15b:66ff je 64-bitni IID.

Looped Multicast

Prema zadanim postavkama, multicast paketi se interno vraćaju čvoru koji ih je poslao. Ovo se događa i za IPv6 i za IPv4 adresiranje.

Razlog ovakvog zadanog ponašanja je taj što kada se šalju multicast paketi, može postojati i slušajuća lokalna multicast aplikacija koja se izvodi na samom hostu koji šalje, kao i negdje na mreži. Ova lokalna aplikacija također mora primati multicast pakete.

Možemo vidjeti ovu multicast lokalnu petlju 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 usporedbi s 0,453 ms) dolazi s adrese Link-Local konfigurirane na samom sučelju enp3s2.

[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
    inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute 
[mark@opy ~]$

Korisnost ping pruža način za suzbijanje lokalne multicast povratne informacije pomoću parametra -L. Ako pošaljemo multicast ping za sve čvorove s ovom zastavicom, tada su odgovori ograničeni na udaljene čvorove. Ne primamo odgovor s Link-Local adrese sučelja 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žda pretpostavljate, unicast Link-Local adrese same po sebi također ne pružaju dovoljno informacija koje bi pokazale koje sučelje treba koristiti da im se dođe. Kao i kod multicast pinga za sve čvorove, također moramo navesti sučelje kao parametar naredbenog retka ping ili ID zone s adresom kada pingate Link-Local adrese.

Ovo vrijeme možemo iskoristiti -cza ograničavanje broja poslanih i primljenih paketa i odgovora ping, budući da 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 ~]$

Pingati (sve) ostale IPv6 adrese?

U ovom smo članku vidjeli kako pingati sve IPv6 čvorove na kanalu pomoću multicast IPv6 adrese svih čvorova ff02::1. Također smo vidjeli kako odrediti koje sučelje koristiti s multicast IPv6 adresom sa svim čvorovima, budući da sama adresa ne može pružiti te informacije. Koristili smo ili opciju naredbenog retka ping, ili odredio sučelje pomoću sufiksa %<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 prema zadanim postavkama vraćaju čvoru za slanje i kako to onemogućiti za pomoćni program ping.

Konačno, pingali smo jednu lokalnu vezu pomoću sufiksa %<zone_id>, budući da same Link-Local adrese također ne pružaju informacije o odlaznom sučelju.

Dakle, što je s pingom svih ostalih čvorova i dobivanjem njihovih globalnih unicast adresa (GUA) (to jest, njihovih javnih adresa na Internetu) ili njihovih jedinstvenih lokalnih unicast adresa (ULA)? Pogledat ćemo to u sljedećem postu na blogu.

To je sve.

Više o našem tečaju možete saznati na bilješke o danu otvorenih vrata.

Izvor: www.habr.com

Dodajte komentar