IPv6 kõigi sõlmede pingimine kanalil

Uue kursuse alguseni on jäänud vaid mõned päevad „Võrguharu” OTUSest. Sellega seoses soovime jagada teiega tõlget kasulikest materjalidest selle teema kohta.

Seeria blogiartiklitest, mis käsitleb IPv6 pingimise (ICMPv6 Echo Request/Echo Reply) tõrkeotsingu näpunäiteid ja soovitusi.

Pange tähele, et kasutan Linuxit (eriti Fedora 31), kuid ping käskude süntaks teistes operatsioonisüsteemides peaks olema väga sarnane.

IPv6 kõigi sõlmede pingimine kanalil

Esimene ja kõige lihtsam soovitus on pingida kõiki IPv6 sõlme kanalil.

IPv6 kasutab kõikide „ühe palve” suhtluste jaoks multifunktsionaalse adresse. IPv6-l puuduvad ülekandeaadressid. See eristab IPv6-d IPv4-st, kus on mitmeid ülekandeaadresse, näiteks „piiratud ülekanne” aadress 255.255.255.255 [RFC1122].

Kuid on olemas „kõikide sõlmede multifunktsionaalne” (üldine multifunktsionaalne) IPv6 aadress, seega kasutame seda kanalil kõigi IPv6 sõlmede pingimiseks. („Ülekande” aadress on tegelikult lihtsalt eraldi nimetatud multifunktsionaalne aadress, mis on rühmitus kõigi sõlmedega. Pange tähele, et näiteks rühma või multifunktsionaalse aadressi bitti sisaldatakse Etherneti ülekandes aadressides kanali tasemel).

Kõikide sõlmede multifunktsionaalne IPv6 aadress kanalile: ff02::1. ff tähistab multifunktsionaalset IPv6 aadressi. Järgmine 0 on mitteaktiivsete bittide märk.

Edasi 2 määrab multifunktsionaalse grupi ala. Erinevalt IPv4 multifunktsionaalsetest aadressidest on IPv6 multifunktsionaalsed aadressid ulatusega. Ulatusväärtus näitab, millises osas võrku on lubatud multifunktsionaalse paketi edastamine. Kui pakett saavutab määratud ulatuse piiri, peab pakett olema tagastatud, hoolimata sellest, kas selle ülemineku loend (Hop Count) on null. Loomulikult, kui ülemineku loend jõuab nulli enne määratud ulatuse piiri, tagastatakse see koheselt. Siin on IPv6 multifunktsionaalsete ulatuste täielik loetelu.

Lõpuks ::1 määratleb kõikide sõlmede multifunktsionaalse grupi.

Aadressist ff02::1 tuleb märkida, et see on mitmetähenduslik. IPv6 sõlm, millel on mitu liidest, nagu marsruuter või mitmesugune host, jagab seda aadressi. ff02::1 ei ole midagi, kus saaks märkida, millisele liidesele ICMPv6 eho-päringud saata või oodata ICMPv6 eho-vastuseid, kui need saabuvad. ff02::1 on kehtiv ja võib kasutada igasugustel liidestel ja kanalitel, mis on ühendatud mitme liidesega sõlmega.

Seetõttu, kui me pingime kõik IPv6 sõlmed kanalil, peame ka kuidagi teatama utiliidile ping millist liidest IPv6 jaoks kasutada.

Liideste määramine on käskluse rida parameeter.

Nagu juba nägime, multicast aadress, mida soovime kasutada — ff02::1 — ei anna mingit teavet selle kohta, millisele liidesele eho-päringu ja eho-vastuse pakette saata ja vastu võtta.

Kuidas me siis määrame liidese, mida kasutada multikast aadressiruumi või unikaalse Link-Local aadressi jaoks?

Esimene ja kõige ilmsem viis on edastada see parameetrina rakendusele, mida me kasutame.

Käskluse jaoks ping edastame selle valikuna -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 vastuseid 6 IPv6 sõlmelt. Vastused tulid sõlme Link-Local IPv6 aadressidelt, mis algavad prefiksiga fe80::/10.

Et ping ei edastanud pidevalt ICMPv6 eho-päringuid seni, kuni me ei katkestanud, me tavaliselt määrame saadetavate pakettide arvu -c valiku kaudu. Kuid see ei luba pingil ka näidata rohkem kui ühte ICMPv6 eho-vastust, kui saadetakse multikast eho-päring ICMPv6. Selle asemel kasutasime valikut -w, et määrata, et ping peaks lõppema 1 sekundi pärast, sõltumata sellest, kui palju eho-päringuid või eho-vastuseid ICMPv6 on saadetud või saadud.

Veel üks asi, millele tähelepanu pöörata, on (DUP!) tulemus teisel ja järgnevatel vastustel. Need paketid identifitseeritakse kui vastuse duplikaadid, kuna nad omavad sama ICMP järjestuse väärtust nagu eraldi ICMPv6 helikutsed, mis saadeti esmalt. Need ilmnevad, kuna multikast ICMPv6 helikutsed toovad kaasa mitmeid individuaalseid unikaalseid vastuseid. Duplikaatide arv on samuti näidatud statistika kokkuvõttes.

Liideste määratlemine — Zone ID

Veel üks viis liidese pakkumiseks kasutamiseks on osa IPv6 aadressi parameetrist.

Saame seda näha ping'i väljundis, kus vastavate IPv6 sõlmede aadressidel on samuti sufiks. %enp3s2, näiteks:

64 baiti from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 ms

See viis liideste määratlemiseks on ametlikult kirjeldatud [RFC4007], „IPv6 määratud aadresside arhitektuur“. Kuigi neid nimetatakse tavaliselt operatsioonisüsteemi liidesees, määratlevad nad tegelikult midagi üldisemat — „ala“ või „ulatus“.

Üldiste või ulatuslike alade olemasolu põhjus on see, et nagu [RFC4007] mainib, võib IPv6 sõlm olla ühendatud mitme erineva IPv6 liidese kaudu sama kanali kaudu. Need liidesed kuuluvad ühe ala hulka.

Tuleb olla võimalik rühmitada mitu liidest sama operatsioonisüsteemi alusel; praegu ei tea ma, kas see on Linuxis võimalik ja kuidas seda teha.

Kasutades sufiksi %, saame 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 baitit from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 baitit from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
64 baitit from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.606 ms (DUP!)
64 baitit from fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=6.23 ms (DUP!)
64 baitit from fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=157 ms (DUP!)
64 baitit from fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=159 ms (DUP!)
64 baitit from fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=161 ms (DUP!)
64 baitit from fe80::23d:e8ff:feec:958c%enp3s2: icmp_seq=1 ttl=64 time=179 ms (DUP!)
 
--- ff02::1%enp3s2 ping statistics ---
1 paketti edastati, 1 saadud, +7 duplikaati, 0% pakettide kadu, aeg 0ms
rtt min/avg/max/mdev = 0.106/82.858/179.216/81.281 ms
 
[mark@opy ~]$

Link-Local aadresside vastused

Sellest all-nodes multikasti pingist saime kokku 6 unikaalset vastust.

Need vastused tulid IPv6 sõlmede unikaalsetelt Link-Local aadressidelt. Näiteks, siit on esimene vastus:

64 baiti from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms

UniCast Link-Local IPv6-aadresse on vajalikud kõigis IPv6-tugevatel liidestel [RFC4291], "IP versiooni 6 aadresside arhitektuur". Selle põhjuseks on see, et IPv6 sõlm on alati automaatselt määratud uni-cast IPv6-aadress, mida ta saab kasutada vähemalt otse ühendatud kanalite kaudu teiste sõlmede suhtlemiseks. See hõlmab sidepidamist teiste hostide rakendustega Link-Local hostide aadresside kaudu.

See lihtsustab protokollide, nagu IPv6 Neighbor Discovery ja OSPFv3, arendamist ja rakendamist. See võimaldab ka lõppkasutaja rakendustel hostides andmeid vahetada kanalil, ilma et oleks vaja mistahes muud IPv6 tugevat infrastruktuuri. Otse ühendatud IPv6 hostide vahel ei ole vajalik IPv6 ruuter või DHCPv6 server ühenduses.

Link-Local aadressid algavad 10-bitisest prefiksist fe80, millele järgneb 54 nullbitti, ja seejärel 64-bitine liidese identifikaator (IID). Ülaltoodud esimeses vastuses 2392:6213:a15b:66ff — see on 64-bitine IID.

Tsükliline Multicast

Vaikimisi saadetakse multikaastpaketid tagasi sisemiselt sõlmele, kes need saadab. See toimub nii IPv6 kui ka IPv4 aadresside puhul.

Selle vaikimisi käitumise põhjuseks on see, et multikaastpakette saadetuna võib samaaegselt töötada kuulav kohaliku multikaasti rakendus, mis töötab saatval hostil, samuti kuskil võrgus. See kohalik rakendus peab samuti saama multikaastpakette.

Saame näha seda multikaastilist lokaalset tsüklit meie ping väljastuses:

[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 andmebaidi
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 (KORD!)
...

Esimene ja kõige kiirem vastus (0,106 ms võrreldes 0,453 ms) tuleb Link-Local aadressilt, mis on seadistatud liidesel 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 viisi multikaast-allika kohaliku tagasiside summutamiseks parameetri kaudu -L. Kui saadame ping all-nodes multikaasti selle lipuga, siis vastused piirduvad eemalolevate sõlmedega. Me ei saa vastust Link-Local aadressilt, mis kuulub saatva seadme liidesele.

[mark@opy ~]$ ping -L -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 andmebaidi
64 baiti fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 aeg=0.383 ms
 
64 baiti fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 aeg=0.467 ms (KORD!)
...

Link-Local Aadressi pinge

Nagu võite arvata, ei paku unicast Link-Local aadressid iseenesest piisavalt teavet, et näidata, millist liidest nende saavutamiseks kasutada. Nagu all-nodes multicasti pinge puhul, tuleb meil samuti määrata liides käsurea parameetrina ping või tsooni ID aadressiga, kui pingime Link-Local aadresse.

Seekord saame kasutada -c, et piirata saadetud ja vastuvõetud paketide arvu ping, kuna sooritame 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 ~]$

Pinge (kõiki) teisi IPv6 aadresse?

Selles artiklis õppisime, kuidas pinge kõiki IPv6 sõlmi kanalil, kasutades all-nodes multicast IPv6 aadressi. ff02::1Samuti nägime, kuidas määrata, millist liidest kasutada all-nodes multicast IPv6 aadressiga, kuna aadress ise ei saa seda teavet anda. Kasutasime kas käsurea parameetrit ping, või määrasime liidese sufiksi kaudu %.

Siis õppisime unicast Link-Local aadresside kohta, mis on aadressid, mida kasutatakse all-nodes multicast ICMPv6 eho-päringutele vastamiseks.

Samuti nägime, kuidas multicast paketid naasevad saadetud sõlme vaikimisi ja kuidas seda utiliidi jaoks välja lülitada. ping.

Lõpuks pingisime üht Link-Local aadressi, kasutades sufiksit %, kuna Link-Local aadressid ise ei paku teavet väljuva liidese kohta.

Kuidas oleks aga pingi kõiki teisi sõlmi ja nende globaalsete unicast aadresside (GUA) (st nende avalike aadresside internetis) või unikaalsete kohalike unicast aadresside (ULA) saamisega? Käsitleme seda järgmises blogiartiklis.

Sellega on kõik.

Kursuse kohta lisateabe saamiseks vaata avatud uste päeva protokolli.

Allikas: habr.com