Uue kiirusega voolu alguseni on jäänud paar päeva alates OTUS. Sellega seoses soovime teiega jagada selleteemalise kasuliku materjali tõlget.
Blogipostituste sari IPv6 pingiprobleemide tõrkeotsingu näpunäidete ja nippide kohta (ICMPv6 Echo Request/Echo Reply)
Pange tähele, et ma kasutan Linuxi (täpsemalt Fedora 31), kuid teiste operatsioonisüsteemide ping-käskude süntaks peaks loodetavasti olema väga sarnane.
Pingige kõik kanali IPv6 sõlmed
Esimene ja lihtsaim näpunäide on pingida kõik lingil olevad IPv6 sõlmed.
IPv6 kasutab multisaateaadresse igat tüüpi üks-mitmele suhtluseks. Leviedastuse (või leviedastuse) IPv6-aadresse pole. See eristab IPv6 IPv4-st, kus on mitut tüüpi leviaadresse, näiteks "piiratud leviedastuse" aadress 255.255.255.255 [RFC1122].
Siiski on olemas kõigi sõlmede multisaadete IPv6-aadress, seega kasutame seda lingi kõigi IPv6-sõlmede pingimiseks. ("Edastusaadress" on tegelikult lihtsalt spetsiaalse nimega multisaateaadress, mis on multisaadete rühm, mis hõlmab kõiki sõlme. Pange tähele, et näiteks "grupi" või multisaate aadressi bitt on Etherneti leviaadressides lingikihis sisse lülitatud ).
Kanali kõigi sõlmede multiedastuse IPv6 aadress: ff02::1. ff tähistab multicast IPv6 aadressi. Järgmine 0 on määramata bittidega lipu osa.
Edasi 2 määrab multisaaterühma ala. Erinevalt multisaate IPv4 aadressidest on multisaadete IPv6 aadressidel ulatus. Ulatuse väärtus näitab võrgu osa, mille kaudu on lubatud multisaatepaketti edastada. Kui pakett jõuab kindlaksmääratud ulatuse piirini, tuleb pakett tühistada, olenemata sellest, kas selle Hop Count väli on nullist erinev. Muidugi, kui hüpete arv jõuab nullini enne määratud multisaaterühma piirini jõudmist, lähtestatakse see ka kohe. Siin on IPv6 multisaate ulatuse täielik loend.
Lõpuks ::1 määrab kõigi sõlmede multisaadete rühma.
Aadressi kohta ff02::1 Tuleb märkida, et see on mitmetähenduslik. Mitme liidesega IPv6 hostil (nt ruuteril või mitme koduga hostil) aadress ff02::1 pole midagi, kus saate määrata, millisele liidesele ICMPv6 kajapäringuid saata või oodata ICMPv6 kajavastuste saamist, kui need saabuvad. ff02::1 on kehtiv ja seda saab kasutada mis tahes liidestes ja kanalites, mis on ühendatud mitme liidese sõlmega.
Seega, kui me pingime lingil kõiki IPv6 sõlme, peame kuidagi ka utiliidile teatama ping IPv6 jaoks, millist liidest kasutada.
Liideste määratlemine – käsurea valik
Nagu me juba nägime, on kõigi sõlmede multiedastusaadress, mida soovime kasutada, − ff02::1 - ei anna teavet selle kohta, millise liidese kaudu saata ja vastu võtta ICMPv6 kajapäringu ja kaja vastuse pakette.
Niisiis, kuidas määrata liidest, mida kasutatakse multisaate aadressiruumi või unicast Link-Local aadressiruumi jaoks?
Esimene ja kõige ilmsem viis on anda see kasutatava rakenduse parameetrina.
Kasulikkuse pärast ping pakume seda 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 ~]$Seda kõigi sõlmede multisaatepingi kasutades saime vastused kuuelt IPv6 sõlmelt. Vastused tulid Link-Local IPv6 sõlme aadressidelt, alustades eesliitega fe80::/10.
Et ping ei jätka ICMPv6 kajapäringute saatmist lõputult, kuni me selle katkestame, tavaliselt määrame suvandi -c kaudu saadetavate pakettide arvu. See aga takistab ka pingil mitme ICMPv6 kajapäringu saatmisel vastu võtta ja kuvada rohkem kui ühte ICMPv6 kajavastust. Selle asemel kasutasime suvandit -w, et määrata, et ping peaks lõppema 1 sekundi pärast, olenemata sellest, kui palju ICMPv6 kajataotlusi või kajavastuseid saadeti või vastu saadeti.
Teine asi, millele tähelepanu pöörata, on (DUP!) väljund teisele ja järgnevatele vastustele. Need paketid tuvastatakse dubleerivate vastustena, kuna neil on sama ICMP jada väärtus, mis algselt saadetud üksikutel ICMPv6 kajapäringutel. Need ilmuvad seetõttu, et ICMPv6 multisaate kajapäring toob kaasa mitu individuaalset unicast vastust. Duplikaatide arv on märgitud ka statistika kokkuvõttes.
Liideste määratlemine – tsooni ID
Teine viis liidese kasutamiseks on osa IPv6 aadressiparameetrist.
Selle näidet näeme pingi väljundis, kus reageerivate IPv6 hostide aadressidel on ka järelliide %enp3s2, näiteks:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msSeda liideste määramise meetodit kirjeldatakse ametlikult artiklis [RFC4007], "IPv6 määratletud aadressiarhitektuur". Kuigi neid nimetatakse tavaliselt operatsioonisüsteemi liidesteks, määratlevad nad tegelikult midagi üldisemat – "tsooni" või "ulatust".
Üldisemate tsoonide või ulatuse tsoonide olemasolu põhjuseks on see, et nagu mainitud [RFC4007]-s, võib IPv6 sõlmel olla mitu erinevat IPv6 liidest, mis on ühendatud sama kanaliga. Need liidesed on sama tsooni liikmed.
Operatsioonisüsteemi tsoonis peaks olema võimalik rühmitada mitu liidest; Praegu ma ei tea, kas see on Linuxis võimalik või kuidas seda teha.
Sufiksi kasutamine %<zone_id>, saame käsurea valiku eemaldada -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-kohaliku aadressi vastused
Sellest kõiki sõlme hõlmavast multisaatepingist saime kokku 6 unikaalset vastust.
Need vastused tulid unicast Link-Local IPv6 hostiaadressidelt. Näiteks siin on esimene vastus:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msUnicast Link-Local IPv6-aadressid on nõutavad kõigis IPv6-toega liidestes [RFC4291], „IP-versiooni 6 aadressiarhitektuur”. Selle põhjuseks on asjaolu, et IPv6 sõlmel on alati automaatselt unicast IPv6 aadress, mida ta saab vähemalt kasutada oma otse ühendatud linkidel teiste sõlmedega suhtlemiseks. See hõlmab teiste hostide rakendustega suhtlemist Link-Local hostiaadresside kaudu.
See lihtsustab selliste protokollide kavandamist ja rakendamist nagu IPv6 Neighbor Discovery ja OSPFv3. Samuti võimaldab see hostide lõppkasutajate rakendustel kanali kaudu suhelda, ilma et oleks vaja kanalil muud toetavat IPv6 infrastruktuuri. Otsesuhtlus ühendatud IPv6 hostide vahel ei nõua ühenduses IPv6 ruuterit ega DHCPv6 serverit.
Link-Local aadressid algavad 10-bitise eesliitega fe80, millele järgneb 54 nullbitti ja seejärel 64-bitine liidese identifikaator (IID). Ülaltoodud esimeses vastuses 2392:6213:a15b:66ff on 64-bitine IID.
Looped Multicast
Vaikimisi tagastatakse multisaatepaketid need saatnud sõlme sisemiselt. See juhtub nii IPv6 kui ka IPv4 aadresside puhul.
Selle vaikekäitumise põhjuseks on see, et multisaadete pakettide saatmisel võib saatvas hostis ja ka kusagil võrgus töötada ka kohalik kuulamisrakendus. See kohalik rakendus peab vastu võtma ka multisaatepakette.
Meie pingi väljundis näeme seda multiedastuse kohalikku ahelat:
[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!)
...Esimene ja kiireim vastus (0,106 ms võrreldes 0,453 ms-ga) pärineb liideses endas konfigureeritud Link-Local aadressist enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Utiliit ping pakub võimalust parameetri abil kohaliku multisaate tagasiside mahasurumiseks -L. Kui saadame selle lipuga kõiki sõlme hõlmava multisaatepingi, on vastused piiratud kaugsõlmedega. Me ei saa saatmisliidese Link-Local aadressilt vastust.
[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-kohalikud aadressid
Nagu võite arvata, ei anna ka unicast Link-Local aadressid iseenesest piisavalt teavet, et näidata, millist liidest nendeni jõudmiseks kasutada. Nagu kõigi sõlmede multisaatepingi puhul, peame ka käsurea parameetrina määrama liidese ping või tsooni ID koos aadressiga Link-Local aadresside pingimisel.
Seekord saame kasutada -csaadetud ja vastuvõetud pakettide ja vastuste arvu piiramiseks ping, kuna teostame unicast pingi.
[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õik kanali IPv6 sõlmed, kasutades kõigi sõlmede multiedastuse IPv6 aadressi ff02::1. Samuti nägime, kuidas määrata, millist liidest kasutada kõigi sõlmede multiedastuse IPv6 aadressiga, kuna aadress ise ei saa seda teavet anda. Kasutasime kas käsurea valikut pingvõi määras liidese järelliide abil %<zone_id>.
Seejärel õppisime tundma unicast Link-Local aadresse, mida kasutatakse kõigi sõlmede multisaadete ICMPv6 kajapäringutele vastamiseks.
Samuti nägime, kuidas multisaadete paketid vaikimisi saatvasse sõlme tagastatakse ja kuidas seda utiliidi jaoks keelata ping.
Lõpuks pingestasime järelliidet kasutades ühe Link-Local aadressi %<zone_id>, kuna ka Link-Locali aadressid ise ei anna teavet väljuva liidese kohta.
Kuidas on siis kõigi teiste sõlmede pingiga ja nende globaalsete unicast-aadresside (GUA-de) (st nende avaliku aadressi Internetis) või ainulaadsete kohalike unicast-aadresside (ULA) hankimisega? Vaatleme seda järgmises blogipostituses.
See on kõik.
Lisateavet meie kursuse kohta saate aadressilt.
Allikas: www.habr.com