Néhány nap van hátra az új áramlás kezdetéig a sebességgel az OTUS-tól. Ezzel kapcsolatban szeretnénk megosztani Önnel a témában hasznos anyagok fordítását.
Blogbejegyzések sorozata az IPv6 ping-problémák hibaelhárításához szükséges tippekről és trükkökről (ICMPv6 Echo Request/Echo Reply)
Kérjük, vegye figyelembe, hogy Linuxot használok (konkrétan Fedora 31), azonban a ping parancs szintaxisa más operációs rendszereken remélhetőleg nagyon hasonló lesz.
Pingelje az összes IPv6 csomópontot egy csatornán
Az első és legegyszerűbb tipp, hogy a link összes IPv6-csomópontját pingelni kell.
Az IPv6 csoportos küldési címeket használ minden típusú egy-a-többhöz kommunikációhoz. Nincsenek broadcast (vagy broadcast) IPv6-címek. Ez különbözteti meg az IPv6-ot az IPv4-től, ahol többféle szórási cím létezik, például a „korlátozott szórási” cím 255.255.255.255 [RFC1122].
Létezik azonban egy „all-nodes multicast” IPv6-cím, ezért ezt fogjuk használni a link összes IPv6-csomópontjának pingelésére. (A "broadcast" cím valójában csak egy speciálisan elnevezett multicast cím, ami egy csoportos küldési csoport, amely magában foglalja az összes csomópontot. Vegye figyelembe, hogy például a "csoport" vagy a csoportos küldési cím bit be van kapcsolva az Ethernet szórási címekben a kapcsolati rétegen ).
Minden csomópontra kiterjedő multicast IPv6-cím a csatornához: ff02::1. ff csoportos IPv6-címet jelöl. A következő 0 a jelzőnek az a része, amelyen a beállított bitek vannak.
További 2 egy multicast csoport területét határozza meg. A csoportos IPv4-címekkel ellentétben a csoportos IPv6-címeknek hatókörük van. A hatókör értéke a hálózatnak azt a részét jelöli, amelyen keresztül csoportos küldésű csomagok továbbítása engedélyezett. Ha egy csomag eléri a megadott hatókör határát, a csomagot el kell dobni, függetlenül attól, hogy a Hop Count mezője nem nulla. Természetesen, ha az ugrások száma eléri a nullát, mielőtt elérné a megadott multicast csoporthatárt, akkor az is azonnal visszaáll. Itt található az IPv6 csoportos küldési hatókörének teljes listája.
Végül, a ::1 egy minden csomópontból álló csoportos küldési csoportot határoz meg.
A címről ff02::1 Meg kell jegyezni, hogy ez kétértelmű. Több interfésszel rendelkező IPv6 gazdagépen, például útválasztón vagy több otthonos gazdagépen a cím ff02::1 nincs semmi, ahol megadhatná, hogy melyik interfésznek küldje el az ICMPv6 echo kéréseket, vagy várjon ICMPv6 echo válaszokat, amikor azok megérkeznek. ff02::1 érvényes, és a több interfész csomóponthoz kapcsolódó bármely interfészen és csatornán használható.
Tehát amikor az összes IPv6-csomópontot pingeljük egy hivatkozáson, valahogyan meg kell mondanunk a segédprogramot is ping IPv6 esetén, melyik interfészt kell használni.
Interfészek meghatározása - Parancssori opció
Mint már láttuk, az összes csomópontra kiterjedő multicast cím, amelyet használni akarunk, a − ff02::1 - nem ad tájékoztatást arról, hogy melyik interfészen kell küldeni és fogadni az ICMPv6 echo kérés és echo válasz csomagokat.
Tehát hogyan adjuk meg a multicast címtérhez vagy az unicast Link-Local címtérhez használandó interfészt?
Az első és legkézenfekvőbb módja az, hogy paraméterként adjuk meg az általunk használt alkalmazáshoz.
A hasznosság miatt ping opción keresztül biztosítjuk -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 ~]$Az összes csomópontra kiterjedő csoportos ping segítségével 6 IPv6-csomóponttól kaptunk választ. A válaszok Link-Local IPv6 csomópontcímekről érkeztek, az előtaggal kezdve fe80::/10.
Hogy ping nem küld tovább ICMPv6 echo kéréseket a végtelenségig, amíg meg nem szakítjuk, általában a -c kapcsolóval adjuk meg a küldendő csomagok számát. Ez azonban azt is megakadályozza, hogy a ping egynél több ICMPv6-visszhang-választ fogadjon el és jelenítsen meg csoportos ICMPv6-visszhang kérés küldésekor. Ehelyett a -w kapcsolóval határoztuk meg, hogy a ping 1 másodperc után fejeződjön be, függetlenül attól, hogy hány ICMPv6 visszhangkérést vagy visszhang-választ küldtek vagy fogadtak.
A másik dolog, amire figyelni kell (DUP!) kimenete a második és az azt követő válaszoknál. Ezeket a csomagokat a rendszer ismétlődő válaszként azonosítja, mivel ugyanaz az ICMP szekvenciaértékük, mint az első helyen elküldött egyedi ICMPv6 visszhangkérések. Azért jelennek meg, mert az ICMPv6 csoportos küldés visszhang kérése több egyedi unicast választ eredményez. A duplikátumok száma a statisztikai összesítésben is feltüntetésre kerül.
Interfészek meghatározása – Zónaazonosító
Egy interfész felfedésének másik módja az IPv6-címparaméter része.
Erre láthatunk példát a ping kimenetben, ahol a válaszoló IPv6-os gazdagépek címei is tartalmazzák az utótagot %enp3s2, például:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msAz interfészek megadásának ezt a módszerét hivatalosan az [RFC4007], „IPv6 által meghatározott címarchitektúra” írja le. Bár általában operációs rendszer interfésznek nevezik őket, valójában valami általánosabbat határoznak meg – egy „zónát” vagy „hatókört”.
Az általánosabb zónák vagy hatókörzónák oka az, hogy az [RFC4007]-ben említettek szerint egy IPv6 csomópont több különböző IPv6 interfésszel is csatlakozhat ugyanahhoz a csatornához. Ezek az interfészek ugyanannak a zónának a tagjai.
Lehetővé kell tenni több interfész csoportosítását egy zónán belül az operációs rendszer alatt; Jelenleg nem tudom, hogy ez lehetséges-e Linux alatt, vagy hogyan kell csinálni.
Az utótag használata %<zone_id>, eltávolíthatjuk a parancssori opciót -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-Helyi címre adott válaszok
Ebből az összes csomópontra kiterjedő multicast pingből összesen 6 egyedi választ kaptunk.
Ezek a válaszok unicast Link-Local IPv6 gazdagépcímekről érkeztek. Például itt van az első válasz:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msUnicast Link-Local IPv6-címek szükségesek minden IPv6-kompatibilis interfészen [RFC4291], „IP-verzió 6 címzési architektúrája”. Ennek az az oka, hogy egy IPv6-csomópontnak mindig automatikusan van egy unicast IPv6-címe, amelyet legalább a közvetlenül kapcsolódó linkjein lévő többi csomóponttal kommunikálhat. Ez magában foglalja a más gazdagépeken lévő alkalmazásokkal való kommunikációt a Link-Local gazdagépcímeken keresztül.
Ez leegyszerűsíti az olyan protokollok tervezését és megvalósítását, mint az IPv6 Neighbor Discovery és az OSPFv3. Azt is lehetővé teszi, hogy a gazdagépeken lévő végfelhasználói alkalmazások a csatornán keresztül kommunikáljanak anélkül, hogy a csatornán bármilyen más támogató IPv6-infrastruktúrát kellene használniuk. A csatlakoztatott IPv6-állomások közötti közvetlen kommunikációhoz nincs szükség IPv6-útválasztóra vagy DHCPv6-kiszolgálóra a kapcsolaton.
A Link-Local címek 10 bites előtaggal kezdődnek fe80, ezt követi 54 nulla bit, majd egy 64 bites interfészazonosító (IID). A fenti első válaszban 2392:6213:a15b:66ff egy 64 bites IID.
Hurkolt multicast
Alapértelmezés szerint a csoportos küldésű csomagok belsőleg visszakerülnek az azokat küldő csomóponthoz. Ez mind az IPv6, mind az IPv4 címzésnél előfordul.
Ennek az alapértelmezett viselkedésnek az az oka, hogy csoportos küldési csomagok küldésekor előfordulhat, hogy magán a küldő gazdagépen, valamint valahol a hálózaton fut egy figyelő helyi multicast alkalmazás. Ennek a helyi alkalmazásnak multicast csomagokat is kell fogadnia.
Ezt a multicast helyi hurkot láthatjuk a ping kimenetünkben:
[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!)
...Az első és leggyorsabb válasz (0,106 ms a 0,453 ms-hoz képest) magán az interfészen konfigurált Link-Local címből származik enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Hasznosság ping lehetőséget biztosít a helyi csoportos küldés visszacsatolásának elnyomására a paraméter használatával -L. Ha minden csomópontra kiterjedő csoportos ping-et küldünk ezzel a jelzővel, akkor a válaszok a távoli csomópontokra korlátozódnak. A küldő felület Link-Local címéről nem kapunk választ.
[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-helyi címek
Ahogy sejthető, az unicast Link-Local címek önmagukban sem adnak elegendő információt ahhoz, hogy jelezzék, melyik felületet kell használni az eléréshez. Az összes csomópontra kiterjedő multicast pinghez hasonlóan az interfészt is meg kell adnunk parancssori paraméterként ping vagy zónaazonosító címmel a Link-Local címek pingelésekor.
Ezúttal használhatjuk -ca küldött és fogadott csomagok és válaszok számának korlátozása ping, mivel unicast pinget hajtunk végre.
[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 (összes) többi IPv6-cím?
Ebben a cikkben azt láthattuk, hogyan kell egy csatornán lévő összes IPv6-csomópontot pingelni egy összes csomópontra kiterjedő csoportos IPv6-cím használatával. ff02::1. Azt is láttuk, hogyan határozzuk meg, hogy melyik interfészt használjuk az összes csomópontot tartalmazó multicast IPv6-címmel, mivel maga a cím nem tudja megadni ezt az információt. Vagy a parancssori opciót használtuk ping, vagy az utótag használatával határozta meg az interfészt %<zone_id>.
Ezután megismerkedtünk az unicast Link-Local címekkel, amelyek az összes csomópontra kiterjedő csoportos ICMPv6 echo kérésekre válaszolnak.
Azt is láttuk, hogy a multicast csomagok alapértelmezés szerint hogyan kerülnek vissza a küldő csomóponthoz, és hogyan lehet ezt letiltani a segédprogramban ping.
Végül egyetlen Link-Local címet pingáltunk az utótag használatával %<zone_id>, mivel maguk a Link-Local címek sem adnak információt a kimenő felületről.
Tehát mi a helyzet az összes többi csomópont pingelésével, és megkapja a globális unicast címüket (GUA-kat) (vagyis nyilvános címeiket az interneten) vagy egyedi helyi unicast címüket (ULA)? Ezt nézzük meg a következő blogbejegyzésben.
Ez minden.
Tanfolyamunkról bővebben itt tájékozódhat.
Forrás: will.com