Már csak néhány nap van hátra az új tanfolyam kezdetéig az OTUS-tól. Ennek kapcsán szeretnénk megosztani veletek egy hasznos anyag fordítását a témában.
Blogbejegyzések sorozata, amely a IPv6 pinggel (ICMPv6 Echo Request/Echo Reply) kapcsolatos hibakeresési tippek és ajánlásokkal foglalkozik.
Kérjük, vegye figyelembe, hogy Linuxot (különösen Fedora 31-et) használok, de a ping parancs szintaxisa más operációs rendszerek esetén remélhetőleg nagyon hasonló lesz.
IPv6 csomópontok pingelése a csatornán
Az első és legegyszerűbb tanács — pingeljük meg az összes IPv6 csomópontot a csatornán.
Az IPv6 multicast címet használ minden egyes kommunikációs típushoz, amely "egy a sokhoz" viszonyban áll. Nincsenek broadcast (széles sávú) IPv6 címek. Ez megkülönbözteti az IPv6-ot az IPv4-től, ahol többféle broadcast cím létezik, például a "limited broadcast" cím 255.255.255.255 [RFC1122].
Van azonban "all-nodes multicast" (általános multicast) IPv6 cím, ezért ezt fogjuk használni az összes IPv6 csomópont pingelésére a csatornán. (A "broadcast" cím valójában csak egy külön néven említett multicast cím, amely tartalmazza az összes csomópontot. Kérjük, vegye figyelembe, hogy például a multicast cím "csoport" bitjei be vannak kapcsolva az Ethernet szintű broadcast címeknél).
Az all-nodes multicast IPv6 cím a csatornán: ff02::1. ff jelöli a multicast IPv6 címet. A következő 0 a nem beállított bitekből álló jelző része.
Ezután 2 meghatározza a multicast csoport terjedelmét. A multicast IPv4 címektől eltérően, a multicast IPv6 címek terjedelmet (scope) rendelkeznek. A scope értéke megmutatja azt a hálózati részt, amelyen a multicast csomagot továbbítani lehet. Amint a csomag eléri a megadott scope határát, a csomagot el kell dobni, függetlenül attól, hogy a hop számláló mezője (Hop Count) nem nullás. Természetesen, ha a hop számláló nullára jut, mielőtt elérné a megadott multicast csoport határát, akkor az is azonnal eltávolításra kerül. Íme a multicast scope IPv6 teljes listája.
Végül, ::1 jelzi az all-nodes multicast csoportot.
A címről ff02::1 meg kell jegyezni, hogy nem egyértelmű. A több interfésszel rendelkező IPv6 csomóponton, mint például a router vagy a multi-hálózati gazdagép, a címben ff02::1 Nincs semmi, ahol megadhatnánk, hogy melyik interfészre küldjünk ICMPv6 echo kéréseket, vagy hol várjunk echo válaszokat ICMPv6-ra, amikor azok megérkeznek. ff02::1 Érvényes és bármelyik interfészen és csatornán használható, amely a több interfésszel rendelkező csomóponthoz kapcsolódik.
Tehát amikor pingelünk minden IPv6 csomópontot a csatornán, valahogy azt is meg kell mondanunk az eszköznek, ping hogy melyik interfészt használja az IPv6 esetében.
Az interfészek meghatározása - parancssori opció
Ahogy már láttuk, az all-nodes multicast cím, amit használni szeretnénk - ff02::1 - nem ad információt arról, hogy melyik interfészre kell elküldeni és fogadni az ICMPv6 echo kéréseket és válaszokat.
Tehát hogyan tudjuk megadni, hogy melyik interfészt használjuk a multicast címek vagy unicast Link-Local címek esetében?
Az első és legnyilvánvalóbb módja az, hogy ezt megadjuk a használt alkalmazás paramétereként.
Az eszközhöz ping az opcióján keresztül adjuk meg -I.
[mark@opy ~]$ ping -w 1 -I enp3s2 ff02::1
ping: Figyelmeztetés: a forráscím másik eszközön lehet kiválasztva: enp3s2
PING ff02::1(ff02::1) from :: enp3s2: 56 adatbájt
64 bájt fe80::1d36:1fff:fefd:82be%enp3s2-tól: icmp_seq=1 ttl=64 idő=0.438 ms
64 bájt fe80::f31c:ccff:fe26:a6d9%enp3s2-tól: icmp_seq=1 ttl=64 idő=0.589 ms (DUP!)
64 bájt fe80::7e31:f5ff:fe1b:9fdb%enp3s2-tól: icmp_seq=1 ttl=64 idő=5.15 ms (DUP!)
64 bájt fe80::f7f8:15ff:fe6f:be6e%enp3s2-tól: icmp_seq=1 ttl=64 idő=58.0 ms (DUP!)
64 bájt fe80::877d:4ff:fe1a:b881%enp3s2-tól: icmp_seq=1 ttl=64 idő=62.3 ms (DUP!)
64 bájt fe80::877d:4ff:fe1a:ad79%enp3s2-tól: icmp_seq=1 ttl=64 idő=62.8 ms (DUP!)
--- ff02::1 ping statisztikák ---
1 csomag küldve, 1 fogadva, +5 másolat, 0% csomagveszteség, idő 0ms
rtt min/avg/max/mdev = 0.438/31.544/62.786/29.566 ms
[mark@opy ~]$Ezzel az all-nodes multicast pinggel 6 IPv6 csomóponttól kaptunk válaszokat. A válaszok Link-Local IPv6 című csomópontoktól érkeztek a következő prefix-szel: fe80::/10.
Ahhoz, hogy ping nem folytatta végtelenül az ICMPv6 echo kérések küldését, amíg meg nem szakítjuk, általában megadjuk az elküldendő csomagok számát a -c opcióval. Azonban ez sem engedi meg, hogy a ping fogadjon és megjelenítsen több mint egy ICMPv6 echo választ, amikor ICMPv6 multicast echo kérést küld. Ehelyett a -w paramétert használtuk, hogy jelezzük, hogy a pingnek 1 másodpercen belül be kell fejeződnie, függetlenül attól, hogy hány echo kérést vagy ICMPv6 echo választ küldtek vagy kaptak.
Még egy dolog, amire figyelni kell, az (DUP!) a második és további válaszok kiírása. Ezeket a csomagokat válaszduplikátumként azonosítják, mivel ugyanazt az ICMP sorozatszámot használják, mint a különálló ICMPv6 echo-kérések, amelyek először lettek elküldve. Azért jelennek meg, mert a multicast ICMPv6 echo-kérés több egyedi unicast választ eredményez. A duplikátumok száma a statisztikai összegzésben is szerepel.
A felületek meghatározása - Zónaazonosító
A felület biztosításának egy másik módja - az IPv6 cím paraméterének egy része.
Ezt megfigyelhetjük a ping kimenetén, ahol az IPv6-nódok válaszadó címei is végződnek. %enp3s2, például:
64 bájt a fe80::1d36:1fff:fefd:82be%enp3s2-ből: icmp_seq=1 ttl=64 time=0.438 msEzt a felületek formális meghatározása [RFC4007] szerint, az „IPv6 címek architektúrája” alapján írják le. Bár általában az operációs rendszer felületének nevezik őket, valójában egy általánosabb dolgot határoznak meg - a „zónát” vagy a „hatáskört”.
A gyakoribb zónák vagy hatáskör zónák létezésének oka az, hogy, mint ahogy azt [RFC4007]-ben említik, egy IPv6 csomópontnak lehet több különböző IPv6 felülete, amelyek ugyanahhoz a hálózathoz csatlakoznak. Ezek a felületek egy zóna tagjai.
Lehetővé kell tenni, hogy a felületek csoportosítva legyenek egy zónán belül az operációs rendszeren; Jelenleg nem tudom, hogy ez Linux alatt lehetséges-e és hogyan lehet ezt végrehajtani.
A végződés használatával %, eltávolíthatjuk a parancssori paramétert -I ping.
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 bájt adat
64 bájt a fe80::2392:6213:a15b:66ff%enp3s2-ből: icmp_seq=1 ttl=64 time=0.106 ms
64 bájt a fe80::1d36:1fff:fefd:82be%enp3s2-ből: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
64 bájt a fe80::f31c:ccff:fe26:a6d9%enp3s2-ből: icmp_seq=1 ttl=64 time=0.606 ms (DUP!)
64 bájt a fe80::7e31:f5ff:fe1b:9fdb%enp3s2-ből: icmp_seq=1 ttl=64 time=6.23 ms (DUP!)
64 bájt a fe80::f7f8:15ff:fe6f:be6e%enp3s2-ből: icmp_seq=1 ttl=64 time=157 ms (DUP!)
64 bájt a fe80::877d:4ff:fe1a:ad79%enp3s2-ből: icmp_seq=1 ttl=64 time=159 ms (DUP!)
64 bájt a fe80::877d:4ff:fe1a:b881%enp3s2-ből: icmp_seq=1 ttl=64 time=161 ms (DUP!)
64 bájt a fe80::23d:e8ff:feec:958c%enp3s2-ből: icmp_seq=1 ttl=64 time=179 ms (DUP!)
--- ff02::1%enp3s2 ping statisztikák ---
1 csomag elküldve, 1 válasz érkezett, +7 duplikátum, 0% csomagveszteség, idő 0ms
rtt min/avg/max/mdev = 0.106/82.858/179.216/81.281 ms
[mark@opy ~]$Link-Local címek válaszai
Erről a minden csomópontra kiterjedő multicast pingelés során összesen 6 egyedi választ kaptunk.
Ezek a válaszok az IPv6 csomópontok unicast Link-Local címeitől érkeztek. Például az első válasz így hangzik:
64 bájt a fe80::2392:6213:a15b:66ff%enp3s2-ből: icmp_seq=1 ttl=64 time=0.106 msA Link-Local IPv6 címeknek minden IPv6-támogatással rendelkező interfészen jelen kell lenniük [RFC4291], az „IPv6 címzés architektúrája” szerint. Ennek oka az, hogy az IPv6 csomópont mindig automatikusan rendelkezik egy unicast IPv6 címével, amelyet a közvetlenül csatlakoztatott csatornák más csomópontjaival való kommunikációhoz használhat. Ez magában foglalja a más gazdagépek alkalmazásaival való kommunikációt a gazdagépek Link-Local címein keresztül.
Ez megkönnyíti olyan protokollok fejlesztését és megvalósítását, mint az IPv6 Szomszéd Felfedezés és az OSPFv3. Ez lehetővé teszi az IPv6 gazdagépeken működő felhasználói alkalmazások számára az adatok csatornán keresztüli cseréjét anélkül, hogy bármilyen más támogató IPv6 infrastruktúrára lenne szükség a csatornán. Közvetlen kapcsolatban álló IPv6 gazdagépekhez nem szükséges IPv6 router vagy DHCPv6 szerver az összeköttetésben.
A Link-Local címek 10 bites prefixszel kezdődnek fe80, amelyet 54 nulla bit követ, majd 64 bites interfész azonosító (IID). A fenti első válaszban 2392:6213:a15b:66ff — ez a 64 bites IID.
Looped Multicast
Alapértelmezés szerint a multicast csomagok visszatérnek a csomóponthoz, amely elküldte őket. Ez mind IPv6, mind IPv4 címezés esetén megtörténik.
Ennek alapértelmezett viselkedésnek az az oka, hogy a multicast csomagok küldésekor lehet, hogy van egy helyi multicast alkalmazás, amely a küldő gazdagépen fut, és valahol a hálózatban is. Ennek a helyi alkalmazásnak szintén meg kell kapnia a multicast csomagokat.
Láthatjuk ezt a multicast helyi ciklust a ping kimenetünkben:
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 adatbájt
64 bájt fe80::2392:6213:a15b:66ff%enp3s2-től: icmp_seq=1 ttl=64 idő=0.106 ms
64 bájt fe80::1d36:1fff:fefd:82be%enp3s2-től: icmp_seq=1 ttl=64 idő=0.453 ms (DUP!)
...Az első és leggyorsabb válasz (0,106 ms a 0,453 ms-hoz képest) a Link-Local címtől érkezik, amely az interfészen van beállítva enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Eszköz ping módot ad a helyi multicast visszajelzés elnyomására a -Lparaméter használatával. Ha ezt a zászlót használva küldünk pinget a többcsatornás multicast-ra, akkor a válaszok csak a távoli csomópontoktól érkeznek. Nem kapunk választ a küldő interfész Link-Local címéről.
[mark@opy ~]$ ping -L -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 adatbájt
64 bájt fe80::1d36:1fff:fefd:82be%enp3s2-től: icmp_seq=1 ttl=64 idő=0.383 ms
64 bájt fe80::f31c:ccff:fe26:a6d9%enp3s2-től: icmp_seq=1 ttl=64 idő=0.467 ms (DUP!)
...Link-Local címek pingelése
Ahogy sejtheted, a unicast Link-Local címek önmagukban nem adnak elegendő információt arról, hogy melyik interfészt kell használni hozzáférésükhöz. Az all-nodes multicast pingeléshez hasonlóan itt is meg kell adnunk az interfészt a parancssori paramétereként. ping vagy a zónaazonosítót a Link-Local cím pingenél.
Ezúttal használhatjuk -c, hogy korlátozzuk a küldött és fogadott csomagok és válaszok számát, ping, mivel unicast pingelést végzünk.
[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 adatbájt
64 bájt érkezett fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 idő=0.395 ms
--- fe80::f31c:ccff:fe26:a6d9%enp3s2 ping statisztikák ---
1 csomag elküldve, 1 fogadva, 0% csomagveszteség, idő 0 ms
rtt min/avg/max/mdev = 0.395/0.395/0.395/0.000 ms
[mark@opy ~]$Pingelni (minden) más IPv6 címet?
Ebben a cikkben láttuk, hogyan pingelhetjük az összes IPv6 csomópontot a csatornán, az all-nodes multicast IPv6 cím használatával. ff02::1Azt is láttuk, hogyan adhatjuk meg, melyik interfészt használjuk az all-nodes multicast IPv6 címhez, mivel maga a cím nem tudja megadni ezt az információt. Használtunk vagy parancssori paramétert, ping, vagy megadtuk az interfészt a suffix segítségével. %.
Ezután beszéltünk a unicast Link-Local címekről, melyek az all-nodes multicast ICMPv6 echo válaszokhoz használt címek.
Azt is láttuk, hogyan térnek vissza a multicast csomagok az alapértelmezett küldő csomóponthoz, és hogyan lehet ezt letiltani az eszköz számára. ping.
Végül pingeltünk egy Link-Local címet, suffix segítségével, %mivel a Link-Local címek önmagukban nem adnak információt a kimenő interfészről.
Mi a helyzet az összes többi csomópont pingelésével és a globális unicast címeik (GUA) (azaz a nyilvános internetes címeik) vagy unikális helyi unicast címeik (ULA) beszerzésével? Ezt a következő blogposztban fogjuk megvizsgálni.
Ezzel véget ért.
Tudjon meg többet tanfolyamunkról a.
Forrás: habr.com
