IPv6 visu mezglu pingošana kanālā

Līdz jaunā kursa uzsākšanai atlicis skaitliski daži dienas „Tīkla inženieris“ no OTUS. Saistībā ar to vēlamies dalīties ar jums noderīga materiāla tulkojumu par šo tēmu.

Sērija rakstu emuārā, kas veltīta padomiem un ieteikumiem kļūdu novēršanai, kas saistīta ar IPv6 pingu (ICMPv6 Echo Request/Echo Reply)

Ņemiet vērā, ka es izmantoju Linux (īpaši Fedora 31), taču ping komandas sintakse citām operētājsistēmām, cerams, būs ļoti līdzīga.

IPv6 visu mezglu pingošana kanālā

Pirmais un vienkāršākais padoms — pingot visus IPv6 mezglus kanālā.

IPv6 izmanto multicast adreses visiem „viens pret daudziem” sakariem. IPv6 adreses neietver broadcast (vai plašsaziņas) adreses. Tas atšķir IPv6 no IPv4, kur pastāv vairāku veidu broadcast adreses, piemēram, „limited broadcast” adrese 255.255.255.255 [RFC1122].

Tomēr ir pieejams “all-nodes multicast” (kopējais multicast) IPv6 adrese, tādēļ mēs to izmantosim visiem IPv6 mezgliem pingojot kanālā. („Plašsaziņas” adrese patiesībā ir vienkārši īpaši nosaukta multicast adrese, kas ir grupas daudzsaziņas adrese, kas ietver visus mezglus. Ņemiet vērā, ka, piemēram, grupas bits vai multicast adrese ir iekļauts broadcast adresēs Ethernet līmenī).

All-nodes multicast IPv6 adrese kanālam: ff02::1. ff apzīmē multicast IPv6 adresi. Nākamais 0 ir daļa no zīmoga ar nenosākuma bitiem.

Tālāk 2 nosaka multicast grupas apgabalu. Atšķirībā no multicast IPv4 adresēm, multicast IPv6 adreses ir ar apgabala redzamību. Apgabala vērtība norāda daļu tīkla, kurā ir atļauts pārsūtīt multicast paketi. Kad pakete sasniedz norādītā apgabala robežu, paketei jābūt izmestai, neatkarīgi no tā, vai tās pārejas skaitītāja (Hop Count) lauks ir nenullīgs. Protams, ja pārejas skaitītājs kļūst nulle pirms norādītā multicast grupas robežas sasniegšanas, tas arī uzreiz tiek izmests. Šeit ir pilns multicast scope IPv6 saraksts.

Visbeidzot, ::1 norāda all-nodes multicast grupu.

Par adresi ff02::1 jāpiebilst, ka tā nav skaidra. Uz IPv6 mezgla ar vairākiem interfeisiem, piemēram, maršrutētāja vai multi-interface hosta, adresē ff02::1 nav nekas, kur varētu norādīt, uz kuru interfeisu nosūtīt ICMPv6 pīkstienu pieprasījumus vai gaidīt, kad saņemta ICMPv6 pīkstiena atbilde, kad tā ierodas. ff02::1 ir derīgs un var tikt izmantots uz jebkura no interfeisiem un kanāliem, kas piesaistīti daudzinterfeisa mezglam.

Tāpēc, kad mēs pīkstinām visus IPv6 mezglus kanālā, mums jānorāda arī utilītēm ping IPv6, kurš interfeiss jāizmanto.

Interfeisu definēšana — komandrindas parametrs

Kā mēs jau redzējām, all-nodes multicasting adrese, kuru mēs vēlamies izmantot — ff02::1 — nesniedz nekādu informāciju par to, uz kuru interfeisu nosūtīt un saņemt echo requests un echo replies ICMPv6.

Tātad, kā mēs varam norādīt interfeisu, kas tiks izmantots multicasting adreses telpai vai unicast Link-Local adresēm?

Pirmais un visredzamākais veids ir sniegt to kā parametru lietojumprogrammai, kuru mēs izmantojam.

Lietojumprogrammai ping mēs norādām to caur opciju -I.

[mark@opy ~]$ ping -w 1 -I enp3s2 ff02::1
ping: Brīdinājums: avota adrese var tikt izvēlēta uz cita ierīces: enp3s2
PING ff02::1(ff02::1) no :: enp3s2: 56 datu baitiem
64 baitus no fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 laiks=0.438 ms
64 baitus no fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 laiks=0.589 ms (DUP!)
64 baitus no fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 laiks=5.15 ms (DUP!)
64 baitus no fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 laiks=58.0 ms (DUP!)
64 baitus no fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 laiks=62.3 ms (DUP!)
64 baitus no fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 laiks=62.8 ms (DUP!)

--- ff02::1 ping statistika ---
1 paka nodota, 1 saņemta, +5 dublikāti, 0% paketes zudums, laiks 0ms
rtt min/avg/max/mdev = 0.438/31.544/62.786/29.566 ms
[mark@opy ~]$

Izmantojot šo all-nodes multicasting ping, mēs saņēmām atbildes no 6 IPv6 mezgliem. Atbildes ieradās no mezgla Link-Local IPv6 adresēm, sākot no prefiksa fe80::/10.

Lai ping nepārtrauca nebeidzamu ICMPv6 pīkstienu pieprasījumu sūtīšanu līdz brīdim, kad mēs to nepārtraucam, parasti mēs norādām sūtāmo pīkstienu skaitu, izmantojot opciju -c. Tomēr tas neļauj ping pieņemt un parādīt vairāk nekā vienu ICMPv6 pīkstiena atbildi, kad tiek nosūtīts multicasting ICMPv6 pīkstiena pieprasījums. Tā vietā mēs izmantojām parametru -w, lai norādītu, ka ping jāpabeidz pēc 1 sekundes, neatkarīgi no tā, cik ICMPv6 pīkstiena pieprasījumu vai atbilžu tika nosūtītas vai saņemtas.

Vēl viena lieta, kurai jāpievērš uzmanība, ir (DUP!) izvada uz otro un nākamajiem atbildēm. Šie pakotnes tiek identificētas kā atbildes dublikāti, jo tām ir tāda pati ICMP secības vērtība kā atsevišķiem ICMPv6 eho pieprasījumiem, kas tika nosūtīti vispirms. Tie parādās, jo multicast ICMPv6 eho pieprasījums rada vairākas individuālas unikālas atbildes. Dublikātu skaits arī norādīts statistikas kopsavilkumā.

Interfeisu definīcija — Zone ID

Vēl viens veids, kā nodrošināt interfeisu izmantošanai, ir daļa no IPv6 adreses parametra.

Mēs varam novērot šī piemēru ping izvadē, kur atbildes IPv6 mezglu adreses arī ir ar sufiksu %enp3s2, piemēram:

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

Šis veids, kā noteikt interfeisus, ir formāli aprakstīts [RFC4007], 'IPv6 adreses arhitektūra'. Lai gan parasti tos dēvē par operētājsistēmas interfeisu, tie patiesībā nosaka kaut ko vispārīgāku — 'zona' vai 'darbības joma'.

Iemesls, kāpēc ir vairāk vispārīgu zonu vai darbības jomu, ir tas, ka, kā pieminēts [RFC4007], IPv6 mezglam var būt vairāki dažādi IPv6 interfeisi, kas pieslēgti vienam un tam pašam kanālam. Šie interfeisi ir vienas zonas locekļi.

Jābūt iespējai grupēt vairākus interfeisus viena operētājsistēmas ietvaros; pašlaik nezinu, vai tas ir iespējams Linux un kā to izdarīt.

Izmantojot sufiksu %, mēs varam noņemt komandrindas parametru -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 statistika ---
1 pakete nosūtīti, 1 saņemti, +7 dublikāti, 0% paketes zudums, laiks 0ms
rtt min/vid/maximum/mdev = 0.106/82.858/179.216/81.281 ms
 
[mark@opy ~]$

Atbildes Link-Local adreses

No šī all-nodes multicast ping mēs saņēmām kopumā 6 unikālas atbildes.

Šīs atbildes ieradās no unikālo Link-Local adresēm IPv6 mezgliem. Piemēram, šī ir pirmā atbilde:

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

Unixcast Link-Local IPv6 adresi ir nepieciešami visos IPv6 atbalstošos saskarnēs [RFC4291], "IPv6 adresēšanas arhitektūra". Iemesls tam ir tas, ka IPv6 mezglam vienmēr automātiski ir Unixcast IPv6 adrese, ko tas var izmantot, vismaz saziņai ar citiem mezgliem caur tieši pievienotajiem kanāliem. Tas ietver saziņu ar citu hostu lietojumprogrammām, izmantojot Link-Local hostu adreses.

Tas atvieglo protokolu, piemēram, IPv6 Neighbor Discovery un OSPFv3, izstrādi un īstenošanu. Tas arī ļauj gala lietotāju lietojumprogrammām uz hostiem apmainīties ar datiem caur kanālu, neprasot citādu atbalstošo infrastruktūru IPv6. Tiešai saziņai starp pievienotajiem IPv6 hostiem nav nepieciešams IPv6 maršrutētājs vai DHCPv6 serveris savienojumā.

Link-Local adreses sākas ar 10 bitu prefiksu fe80, kam seko 54 nulles biti, un pēc tam 64 bitu saskarnes identifikators (IID). Iepriekš minētajā pirmajā atbildē 2392:6213:a15b:66ff — tas ir 64 bitu IID.

Cikliskā Multicast

Noklusējuma multikast paketes tiek atgrieztas iekšēji mezglam, kas tās nosūtījis. Tas attiecas uz abām IPv6 un IPv4 adresācijām.

Šī noklusējuma uzvedība ir saistīta ar to, ka, nosūtot multikast paketes, var būt arī vietējā multikast lietojumprogramma, kas darbojas tieši nosūtītāja hostā, kā arī kaut kur tīklā. Šai vietējai lietojumprogrammai arī ir jāsaņem multikast paketes.

Mēs varam redzēt šo multikast vietējo ciklu mūsu ping izvadē:

[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 datu baiti
64 baiti no fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 laiks=0.106 ms
64 baiti no fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 laiks=0.453 ms (DUP!)
...

Pirmais un ātrākais atbildes laiks (0,106 ms salīdzinājumā ar 0,453 ms) rodas no Link-Local adreses, kas iestatīta pašā saskarnē enp3s2.

[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
    inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute 
[mark@opy ~]$

Rīks ping nodrošina veidu, kā apspiest lokālo atgriezenisko saiti multikastā ar palīdzību parametra -L. Ja mēs sūtām ping visiem mezgliem ar šo flagu, tad atbildes tika ierobežotas uz attāliem mezgliem. Mēs nesaņemam atbildi no nosūtītāja Link-Local adreses saskarnes.

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

Ping Link-Local adresi

Kā varat nojaust, unikastie Link-Local adresi paši par sevi arī nesniedz pietiekamu informāciju, lai norādītu, kuru interfeisu izmantot to sasniegšanai. Tāpat kā visiem mezglu multicast pingam, mums arī jānorāda interfeiss kā komandrindas parametrs ping vai zone ID ar adresi, kad pingojam Link-Local adresus.

Šoreiz mēs varam izmantot -c, lai ierobežotu nosūtīto un saņemto pakotņu un atbilžu skaitu ping, jo mēs veicam unikastu ping.

[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 datu baitus
64 baiti no fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 laiks=0.395 ms
 
--- fe80::f31c:ccff:fe26:a6d9%enp3s2 ping statistika ---
1 pakotne nosūtīta, 1 saņemta, 0% pakotņu zudums, laiks 0ms
rtt min/avg/max/mdev = 0.395/0.395/0.395/0.000 ms
[mark@opy ~]$

Jāpingojas (visiem) citiem IPv6 adresēm?

Šajā rakstā mēs redzējām, kā pingot visus IPv6 mezglus kanalā, izmantojot all-nodes multicast IPv6 adresi ff02::1. Mēs arī redzējām, kā norādīt, kuru interfeisu izmantot ar all-nodes multicast IPv6 adresi, jo pats adrese nevar sniegt šo informāciju. Mēs izmantojām vai nu komandrindas parametru ping, vai norādījām interfeisu caur sufiksu %.

Pēc tam mēs uzzinājām par unikastajiem Link-Local adresiem, kuri tiek izmantoti, lai atbildētu uz all-nodes multicast ICMPv6 echo pieprasījumiem.

Mēs arī redzējām, kā multicast pakotnes tiek atgrieztas sūtītāja mezglam pēc noklusējuma un kā to atslēgt rīkam ping.

Visbeidzot, mēs propingojām vienu Link-Local adresi, izmantojot sufiksu %, jo Link-Local adreses pašas par sevi arī nesniedz informāciju par izejošo interfeisu.

Kā būtu ar visiem pārējiem mezgliem pingojot un iegūstot to globālās unikast adreses (GUA) (t.i., to publiskās adreses internetā) vai to unikālo lokālo unikast adreses (ULA)? Mēs to apspriedīsim nākamajā emuāra rakstā.

Uz to arī viss.

Uzzināt vairāk par mūsu kursu var dienas atvērto durvju ierakstā.

Avots: habr.com