Uue kursuse voogude alguseni jääb veel vaid paar päeva OTUS-elt. Seoses sellega soovime teiega jagada kasuliku materjali tõlget teemal.
Artiklite seeria blogis, mis on pühendatud seotud probleemide tõrkeotsimise näpunäidetele ja soovitustele, mis käsitlevad IPv6 pingi (ICMPv6 Echo Request/Echo Reply) küsimusi
Pange tähele, et kasutan Linuxit (nimelt Fedora 31), kuid ping-käskluse süntaks teiste operatsioonisüsteemide jaoks peaks olema loodetavasti väga sarnane.
IPv6 sõlmede pingi kontrollimine kanalil
Esimene ja kõige lihtsam soovitus on pingida kõik IPv6 sõlmed kanalil.
IPv6 kasutab multicasti aadresse kõikide üks-ühele ja üks-ühele suhtlemise liikide jaoks. IPv6 aadresse ei ole, seega puuduvad saadetised (broadcast) nagu IPv4-s, kus on mitu tüüpi saadetiste aadresse, näiteks „limited broadcast“ aadress 255.255.255.255 [RFC1122].
Kuid olemas on 'all-nodes multicast' (ühine multikas) IPv6-aadress, seega kasutame seda, et pingida kõiki IPv6 sõlmi kanalil. ('Laiaulatuslik' aadress on tegelikult lihtsalt spetsiaalselt nimetatud multikas-aadress, mis on rühm multimeedia jaotust, mis hõlmab kõiki sõlmi. Pange tähele, et näiteks 'grupi' või multikas-aadressi bitti on kaasatud Etherneti kihtide tasemel laiaulatuslikesse aadressidesse.)
Kanalile kuuluv all-nodes multicast IPv6-aadress: ff02::1. ff tähistab multikas IPv6-aadressi. Järgmine 0 on osa lipust, kus bitid on seadistamata.
Seejärel 2 määrab multicast-grupi ulatuse. Erinevalt IPv4 multicast-aadressidest, IPv6 multicast-aadressid omavad ulatust (scope). Ulatuse väärtus näitab võrguosa, mille kaudu multicast-paketti tohib edastada. Kui pakett jõuab määratud ulatuse piirile, peab pakett olema diskvalifitseeritud, sõltumata sellest, kas tema üleminekute arvu väli (Hop Count) on null. Loomulikult, kui üleminekute arv saavutab nulli enne, kui määratud multicast-grupi piirini on jõutud, tühistatakse see samuti koheselt. Siin on täielik IPv6 multicast ulatuste nimekiri.
Lõpuks, ::1 näitab all-nodes multicast gruppi.
Aadressist ff02::1 tuleb märkida, et see on mitm nghĩa. IPv6 sõlmes, millel on mitu liidest, nagu ruuter või multi-võrgu host, aadressil ff02::1 ei ole midagi, kus oleks võimalik näidata, millisele liidesele saata ICMPv6 echo-requests või oodata ICMPv6 echo-vastasid, kui need saabuvad. ff02::1 kehtib ja seda võib kasutada igast liidesest ja kanalist, mis on ühendatud multi-liidese sõlmega.
Seetõttu, kui me pingime kõiki IPv6 sõlmi kanalil, peame teavitama utiliiti ka kuidagi. ping IPv6 puhul, millist liidest kasutada.
Liideste määratlemine - käskluste rida
Nagu me juba nägime, all-nodes multicast aadress, mida soovime kasutada - ff02::1 - ei anna mingeid andmeid selle kohta, millisele liidesele saata ja vastu võtta ICMPv6 echo-päringute ja echo-vastuste pakette.
Nii et kuidas me saame näidata liidest, mida kasutatakse multikaadresside või unikaalsete Link-Local aadresside jaoks?
Esimene ja ilmselge viis - edastada see rakenduse parameetrina, mida kasutame.
Tööriista jaoks ping edastame me selle valiku kaudu -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 ~]$Selle all-nodes multicast pingi abil saime mehaaniliselt vastuseid 6 IPv6-sõlmelt. Vastused anti Link-Local IPv6-aadressidelt, mis algavad prefixesest fe80::/10.
Et ping mitte jätkama lõputult ICMPv6 ehho-päringute saatmist seni, kuni me ei katkesta seda, tavaliselt märkime meil pakettide arvu, mida saata, valiku -c kaudu. Kuid see ei võimalda ka pingil vastu võtta ja kuvada enam kui ühte ICMPv6 ehho-vastust ICMPv6 multicast ehho-päringu saatmisel. Selle asemel kasutasime parameetrit -w, et näidata, et ping peaks lõpetama 1 sekundi pärast, olenemata sellest, kui palju ehho-päringuid või ICMPv6 ehho-vastuseid on saadetud või saadud.
Veel üks asi, millele tähelepanu pöörata, on (DUP!) väljund teise ja järgneva vastuse puhul. Need paketid tuvastatakse kui vastuse duplikaadid, kuna neil on sama ICMP järjestuse väärtus nagu esmakordselt saadetud individuaalsed ehho-päringud ICMPv6. Need ilmuvad, kuna ICMPv6 multicast ehho-päring toob kaasa mitmeid individuaalseid unicast vastuseid. Duplikaatide arv on samuti näidatud statistika kokkuvõttes.
Liideste määramine — Zone ID
Veel kasutatavate IPv6 aadresside parameter on sadama piires oleva vahemiku näitamine.
Seda näeme ping-i väljundis, kus vastavate IPv6 sõlmede aadressidel on samuti sufiks. %enp3s2, näiteks:
64 baiti fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 aeg=0,438 msSeda meetodit, millega määrata liideseid, on ametlikult kirjeldatud [RFC4007], "IPv6 aadresside määratletud arhitektuur". Kuigi neid nimetatakse sageli operatsioonisüsteemi liideseks, määratlevad nad tegelikult midagi üldisemat — "vahemik" või "väljaulatus".
Üks põhjus, miks on vaja laiemate vahemike või ulatuse tsoone, seisneb selles, et nagu mainitakse [RFC4007], võib IPv6 sõlmel olla mitu erinevat IPv6 liidest, mis on ühendatud ühe ja sama kanali kaudu. Need liidesed kuuluvad ühte tsooni.
Tuleb olla võimalik rühmastada mitu liidest tsoonis operatsioonisüsteemi piires; hetkel ei tea ma, kas see on Linuxis võimalik ja kuidas seda teha.
Kasutan sufiksit %, et saaksime eemaldada käsurea parameetri -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 aadresside vastused
Selle all-nodes multicast ping'i tulemusena saime kokku 6 unikaalset vastust.
Need vastused tulid unikaalsest Link-Local aaddrendi IPv6 sõlmedelt. Näiteks esimene vastus:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msUniquecast Link-Local IPv6-aadressid on vajalikud kõigil IPv6-toega liidesetel [RFC4291], 'IP versioon 6 aadressimise arhitektuur'. Selle põhjuseks on see, et IPv6 sõlmel on alati automaatselt unikaalne IPv6-aadress, mida ta saab kasutada vähemalt otseühendatud kanalite kaudu teiste sõlmede suhtlemiseks. See hõlmab hostide rakendustega suhtlemist hostide Link-Local aadresside kaudu.
See lihtsustab protokollide, nagu IPv6 naabri avastamine ja OSPFv3, arendamist ja rakendamist. See võimaldab ka lõppkasutajate rakendustel hostides vahetada andmeid kanalil, ilma et oleks vaja mingit muud toetavat IPv6 infrastruktuuri. Otseühendatud IPv6 hostide vahel ei ole vaja IPv6 ruuterit ega DHCPv6 serverit ühenduses.
Link-Local aadressid algavad 10-bitise prefiksiga fe80, millele järgneb 54 null-bitit ja seejärel 64-bitine liidese identifikaator (IID). Ülaltoodud esimeses vastuses 2392:6213:a15b:66ff — see on 64-bitine IID.
Looped Multicast
Vaikimisi tagastatakse multikaastpaketid siseuudiselt sõlmele, kes need saatnud on. See toimub nii IPv6 kui ka IPv4 aadresside puhul.
Selle defekti põhjus on see, et multicast-pakettide saatmise ajal võib samas saatmise hostis töötada ka kuulav kohaliku multicast-rakendus, nagu ka kusagil võrgus. See kohaliku rakendus peab samuti multicast-pakette vastu võtma.
Me saame näha seda multicast-kohalikku tsüklit meie ping-väljundis:
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 andme baidi
64 baiti fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 aeg=0.106 ms
64 baiti fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 aeg=0.453 ms (DUP!)
...Esimene ja kiirem vastus (0,106 ms võrreldes 0,453 ms) tuleb Link-Local aadressilt, mis on seadistatud samal liidesel enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 ulatus link noprefixroute
[mark@opy ~]$Tööriist ping pakub viisi lokaalsete multicast jaotuste tagasiside suunamiseks parameetri abil -L. Kui me saadame ping all-nodes multicast selle toggle'ga, siis vastused piirdub vaid kaugete sõlmedega. Me ei saa vastust saatja liidese Link-Local aadressilt.
[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!)
...Link-Local Aadresside pinge
Kuidas arvata võite, üksikadressi Link-Local aadressid iseenesest ei paku piisavalt teavet, et näidata, millist liidest nende saavutamiseks kasutada. Nagu kõikide sõlmpunktide multicast-pingil, peame ka liidese näitama käsurea argumendina. ping või zone ID koos aadressiga Link-Local aadresside pingimisel.
Seekord saame kasutada -c, et piirata saadetavate ja vastuvõetavate pakettide arvu. ping, kuna teostame üksikpinget.
[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 ~]$Pingida (kõiki) teisi IPv6-aadresse?
Selles artiklis nägime, kuidas pingida kõiki IPv6-sõlmi kanalil, kasutades all-nodes multicast IPv6-aadressi. ff02::1. Samuti oleme näinud, kuidas näidata, millist liidest kasutada all-nodes multicast IPv6-aadressiga, kuna aadress ise ei suuda seda teavet anda. Kasutasime kas käsurea parameetrit ping, või näitasime liidest sufiksi kaudu %.
. Siis õppisime unikast Link-Local aadressidest, mis on aadressid, mida kasutatakse all-nodes multicast ICMPv6 echo-päringute vastamiseks.
Olemegi näinud, kuidas multicast paketid tagastatakse saatvale sõlmele vaikimisi ja kuidas seda utiliidis välja lülitada ping.
. Lõpuks pingerisime ainsa Link-Local aadressi kasutanud sufiksiga %, kuna Link-Local aadressid ise ei anna samuti teavet väljuva liidese kohta.
Ent kuidas on olukord kõigi teiste sõlmede pingimise ja nende globaalse unikast aadressi (GUA) (st nende avaliku IP-aadressi) või ainulaadse kohaliku unikast aadressiga (ULA) saamisega? Räägime sellest järgmises blogiartiklis.
Sellega on kõik.
Meie kursuse kohta saate rohkem teada.
Allikas: habr.com
