Numai câteva zile rămân până la începerea noului curs de la OTUS. În acest sens, dorim să vă împărtășim traducerea unui material util pe acest subiect.
O serie de articole pe blog dedicate sfaturilor și recomandărilor pentru soluționarea problemelor legate de ping-ul IPv6 (ICMPv6 Echo Request/Echo Reply)
Rețineți că folosesc Linux (în special Fedora 31), însă sintaxa comenzii ping pentru alte sisteme de operare ar trebui să fie foarte asemănătoare.
Pingul tuturor nodurilor IPv6 pe canal
Primul și cel mai simplu sfat este să pingi toate nodurile IPv6 de pe canal.
IPv6 folosește adrese multicast pentru toate tipurile de comunicare „unu la mulți”. Nu există adrese broadcast (sau de difuzare) IPv6. Aceasta diferențiază IPv6 de IPv4, unde există mai multe tipuri de adrese broadcast, de exemplu, adresa „limited broadcast” 255.255.255.255 [RFC1122].
Totuși, există o adresă IPv6 „all-nodes multicast” (multicast general), așa că o vom folosi pentru a pinga toate nodurile IPv6 de pe canal. (Adresa „broadcast” este de fapt doar o adresă multicast denumită special care include toate nodurile. Rețineți că, de exemplu, bitul „grupului” sau adresa multicast este inclus în adresele broadcast Ethernet la nivel de canal).
Adresa IPv6 all-nodes multicast pentru canal: ff02::1. ff indică o adresă multicast IPv6. Următorul 0 este partea cu flag-uri neatribuite.
Următorul 2 definește domeniul grupului multicast. Spre deosebire de adresele multicast IPv4, adresele multicast IPv6 au un domeniu (scope). Valoarea domeniului indică partea rețelei prin care este permisă retransmiterea pachetului multicast. Odată ce pachetul atinge limitele domeniului specificat, pachetul trebuie să fie eliminat, indiferent dacă câmpul său de contor de salt (Hop Count) este diferit de zero. Desigur, dacă contorul de salt ajunge la zero înainte de a atinge limita grupului multicast specificat, acesta este de asemenea eliminat imediat. Iată lista completă a domeniilor multicast IPv6.
În cele din urmă, ::1 indică grupul all-nodes multicast.
Despre adresa ff02::1 se cuvine să observăm că este ambiguă. Pe un nod IPv6 cu mai multe interfețe, cum ar fi un router sau un gazdă multi-rețea, în adresă ff02::1 Nu există nimic care să indice ce interfață să folosească pentru a trimite cereri de echo ICMPv6 sau pentru a aștepta primirea răspunsurilor de echo ICMPv6 atunci când acestea sosesc. ff02::1 Este valid și poate fi utilizat pe oricare dintre interfețele și canalele conectate la un nod multinterfețe.
Așadar, când facem ping la toate nodurile IPv6 de pe canal, trebuie să comunicăm cumva utilitarului ping ce interfață să folosească pentru IPv6.
Definirea interfețelor este un parametru al liniei de comandă.
Așa cum am văzut deja, adresa multicast all-nodes pe care dorim să o folosim — ff02::1 — nu oferă nicio informație despre ce interfață să folosească pentru a trimite și a primi pachete de cereri de echo și răspunsuri de echo ICMPv6.
Deci, cum putem specifica interfața care va fi utilizată pentru spațiile de adresare multicast sau adresele unicast Link-Local?
Primul și cel mai evident mod este să o oferim ca parametru pentru aplicația pe care o folosim.
Pentru utilitarul ping o oferim prin opțiunea -I.
[mark@opy ~]$ ping -w 1 -I enp3s2 ff02::1
ping: Avertisment: adresa sursă ar putea fi selectată pe un dispozitiv diferit de: enp3s2
PING ff02::1(ff02::1) de la :: enp3s2: 56 bytes de date
64 bytes de la fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 ms
64 bytes de la fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.589 ms (DUP!)
64 bytes de la fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=5.15 ms (DUP!)
64 bytes de la fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=58.0 ms (DUP!)
64 bytes de la fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=62.3 ms (DUP!)
64 bytes de la fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=62.8 ms (DUP!)
--- statistici ping ff02::1 ---
1 pachete trimise, 1 primite, +5 duplicate, 0% pierdere de pachete, timp 0ms
rtt min/med/max/mdev = 0.438/31.544/62.786/29.566 ms
[mark@opy ~]$Folosind acest ping multicast all-nodes, am primit răspunsuri de la 6 noduri IPv6. Răspunsurile au venit de la adresele IPv6 Link-Local nodale, începând cu prefixul fe80::/10.
Pentru a ping nu a continuat să trimită cereri de echo ICMPv6 până când nu l-am oprit, de obicei specificăm numărul de pachete de trimis prin opțiunea -c. Totuși, aceasta nu permite ping-ului să primească și să afișeze mai mult de un răspuns de echo ICMPv6 la trimiterea unei cereri de echo multicast ICMPv6. În schimb, am folosit parametrul -w pentru a indica că ping-ul ar trebui să se termine după 1 secundă, indiferent de câte cereri de echo sau răspunsuri de echo ICMPv6 au fost trimise sau primite.
Un alt aspect de care trebuie să țineți cont este (DUP!) rezultatul în a doua și cele ulterioare răspunsuri. Aceste pachete sunt identificate ca duplicate de răspuns, deoarece au aceeași valoare a secvenței ICMP ca și cererile echo ICMPv6 individuale trimise inițial. Ele apar deoarece cererile echo ICMPv6 multicast conduc la mai multe răspunsuri unicast individuale. Numărul de duplicate este, de asemenea, indicat în rezumatul statisticilor.
Definirea interfețelor — ID-ul Zonei
O altă modalitate de a oferi o interfață pentru utilizare este partea parametrului adresei IPv6.
Putem observa un exemplu al acestui lucru în rezultatul ping, unde adresele nodurilor IPv6 care răspund au, de asemenea, un sufix %enp3s2, de exemplu:
64 bytes de la fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msAceastă modalitate de a specifica interfețele este descrisă formal în [RFC4007], „Arhitectura cu adrese IPv6 specificate”. Deși de obicei sunt numite interfața sistemului de operare, ele definesc de fapt ceva mai general — „zona” sau „domeniul de valabilitate”.
Motivul pentru care există zone mai generale sau zone de domeniu este că, așa cum se menționează în [RFC4007], un nod IPv6 poate avea mai multe interfețe IPv6 diferite conectate la același canal. Aceste interfețe sunt membri ai unei singure zone.
Trebuie să fie posibil să grupăm mai multe interfețe în cadrul zonei sub sistemul de operare; în prezent, nu știu dacă este posibil acest lucru în Linux și cum se poate face.
Folosind sufixul %, putem elimina parametrul din linia de comandă -I ping.
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 bytes de date
64 bytes de la fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes de la fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
64 bytes de la fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.606 ms (DUP!)
64 bytes de la fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=6.23 ms (DUP!)
64 bytes de la fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=157 ms (DUP!)
64 bytes de la fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=159 ms (DUP!)
64 bytes de la fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=161 ms (DUP!)
64 bytes de la fe80::23d:e8ff:feec:958c%enp3s2: icmp_seq=1 ttl=64 time=179 ms (DUP!)
--- statistica ping-ului ff02::1%enp3s2 ---
1 pachet transmis, 1 primit, +7 duplicate, 0% pierdere de pachete, timp 0ms
rtt min/med/max/mdev = 0.106/82.858/179.216/81.281 ms
[mark@opy ~]$Răspunsurile adreselor Link-Local
Din acest ping multicast al tuturor nodurilor, am primit un total de 6 răspunsuri unice.
Aceste răspunsuri au venit de la adrese unicast Link-Local ale nodurilor IPv6. De exemplu, iată primul răspuns:
64 bytes de la fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msAdresele unicast Link-Local IPv6 sunt necesare pe toate interfețele care suportă IPv6 [RFC4291], „Arhitectura adresării IP versiunea 6”. Motivul este că un nod IPv6 are întotdeauna automat o adresă IPv6 unicast pe care o poate utiliza, cel puțin pentru a comunica cu alte noduri prin canalele sale direct conectate. Aceasta include comunicarea cu aplicațiile altor gazde prin adresele Link-Local ale gazdelor.
Acest lucru simplifică dezvoltarea și implementarea protocoalelor, cum ar fi Descoperirea Vecinilor IPv6 și OSPFv3. De asemenea, permite aplicațiilor utilizatorului final de pe gazde să schimbe date prin canal, fără a necesita pe canal vreo altă infrastructură suportă IPv6. Pentru comunicarea directă a gazdelor conectate, nu este necesar un router IPv6 sau un server DHCPv6 în conexiune.
Adresele Link-Local încep cu un prefix de 10 biți fe80, urmat de 54 de biți zero și apoi de un identificator de interfață de 64 de biți (IID). În prima răspuns de mai sus, 2392:6213:a15b:66ff — acesta este IID-ul de 64 de biți.
Multicast Loopew
În mod implicit, pachetele multicast se returnează intern la nodul care le trimite. Acest lucru se aplică atât adresărilor IPv6, cât și IPv4.
Cauza acestui comportament implicit este că, atunci când se trimit pachete multicast, poate exista, de asemenea, o aplicație multicast locală care ascultă, care rulează pe gazda care trimite, la fel ca și în altă parte în rețea. Această aplicație locală ar trebui, de asemenea, să primească pachetele multicast.
Putem observa acest ciclu local multicast în ieșirea comenzii noastre ping:
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 bytes de date
64 bytes din fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes din fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
...Primul și cel mai rapid răspuns (0.106 ms comparativ cu 0.453 ms) provine de la adresa Link-Local, configurată pe interfața enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Utilitarul ping oferă o modalitate de a suprima feedbackul local al multicastului folosind parametrul -L. Dacă trimitem un ping multicast all-nodes cu această opțiune, răspunsurile se limitează la nodurile de la distanță. Nu primim un răspuns de la adresa Link-Local a interfeței trimisătorului.
[mark@opy ~]$ ping -L -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 bytes de date
64 bytes din fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.383 ms
64 bytes din fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.467 ms (DUP!)
...Ping pentru adrese Link-Local
Așa cum vă puteți imagina, adresele Link-Local unicast nu oferă suficiente informații pentru a indica ce interfață ar trebui utilizată pentru a le atinge. La fel ca în cazul pingerii multicast all-nodes, trebuie să specificăm interfața ca parametru al liniei de comandă. ping sau ID-ul zonei cu adresa atunci când pinguim adrese Link-Local.
De data aceasta putem folosi -c, pentru a limita numărul de pachete și răspunsuri trimise și primite ping, deoarece executăm un 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 date de tip data
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.395 ms
--- fe80::f31c:ccff:fe26:a6d9%enp3s2 statistici ping ---
1 pachet transmis, 1 primit, 0% pierdere de pachete, timp 0ms
rtt min/med/max/mdev = 0.395/0.395/0.395/0.000 ms
[mark@opy ~]$Ping pentru (toate) celelalte adrese IPv6?
În acest articol, am văzut cum să pinguim toate nodurile IPv6 de pe canal, folosind adresa multicast IPv6 all-nodes. ff02::1De asemenea, am văzut cum să specificăm ce interfață să folosim cu adresa multicast IPv6 all-nodes, deoarece adresa în sine nu poate oferi aceste informații. Am folosit fie un parametru al liniei de comandă ping, fie am specificat interfața prin sufix. %.
Apoi, am învățat despre adresele Link-Local unicast, care sunt adresele utilizate pentru răspunsurile la cererile de ecou multicast all-nodes ICMPv6.
De asemenea, am văzut cum pachetele multicast se întorc la nodul de trimitere implicit și cum să dezactivăm acest lucru pentru utilitar. ping.
În cele din urmă, am pinguit o adresă Link-Local unică, folosind sufixul %, deoarece adresele Link-Local în sine nu oferă informații despre interfața de ieșire.
Ce despre pingul tuturor celorlalte noduri și obținerea adreselor lor unicast globale (GUA) (adică adresele lor publice pe Internet) sau a adreselor lor unicast locale unice (ULA)? Vom discuta acest lucru în articolul următor de pe blog.
Asta e tot.
Aflați mai multe despre cursul nostru în.
Sursa: habr.com
