Atlikušas dažas dienas līdz jaunas plūsmas sākumam ar ātrumu no OTUS. Šajā sakarā mēs vēlamies dalīties ar jums noderīga materiāla tulkojumu par šo tēmu.
Emuāra ziņu sērija par padomiem un trikiem IPv6 ping problēmu novēršanai (ICMPv6 Echo Request/Echo Reply)
Lūdzu, ņemiet vērā, ka es izmantoju Linux (īpaši Fedora 31), tomēr citu operētājsistēmu ping komandas sintaksei, cerams, vajadzētu būt ļoti līdzīgai.
Ping visiem IPv6 mezgliem kanālā
Pirmais un vienkāršākais padoms ir ping visiem IPv6 mezgliem saitē.
IPv6 izmanto multiraides adreses visu veidu saziņai viens pret daudziem. Nav apraides (vai apraides) IPv6 adrešu. Tas atšķir IPv6 no IPv4, kur ir vairāki apraides adrešu veidi, piemēram, “ierobežotā apraides” adrese 255.255.255.255 [RFC1122].
Tomēr ir “visu mezglu multiraides” IPv6 adrese, tāpēc mēs to izmantosim, lai ping visiem IPv6 mezgliem saitē. ("Apraides" adrese patiesībā ir tikai īpaši nosaukta multiraides adrese, kas ir multiraides grupa, kas ietver visus mezglus. Ņemiet vērā, ka, piemēram, "grupas" vai multiraides adreses bits ir ieslēgts Ethernet apraides adresēs saites slānī. ).
Visu mezglu multiraides IPv6 adrese kanālam: ff02::1. ff apzīmē multiraides IPv6 adresi. Nākamais 0 ir karoga daļa ar atiestatītiem bitiem.
Tālāk 2 definē multiraides grupas apgabalu. Atšķirībā no multiraides IPv4 adresēm, multiraides IPv6 adresēm ir darbības joma. Tvēruma vērtība norāda tīkla daļu, pa kuru ir atļauts pārsūtīt multiraides paketi. Kad pakete sasniedz norādītās darbības jomas robežu, pakete ir jāatmet neatkarīgi no tā, vai tās apgriezienu skaita lauks nav nulle. Protams, ja apiņu skaits sasniedz nulli pirms noteiktās multiraides grupas robežas sasniegšanas, tas arī tiek nekavējoties atiestatīts. Šeit ir pilns IPv6 multiraides tvēruma saraksts.
Visbeidzot, ::1 norāda visu mezglu multiraides grupu.
Par adresi ff02::1 Jāatzīmē, ka tas ir neskaidrs. Adrese IPv6 resursdatorā ar vairākām saskarnēm, piemēram, maršrutētājā vai daudzvietīgā resursdatorā ff02::1 nav nekā, kur jūs varat norādīt, kuram interfeisam nosūtīt ICMPv6 atbalss pieprasījumus vai sagaidīt ICMPv6 atbalss atbilžu saņemšanu, kad tās pienāk. ff02::1 ir derīgs un to var izmantot jebkurā no saskarnēm un kanāliem, kas pievienoti vairāku interfeisu mezglam.
Tātad, kad mēs piesūtām visus IPv6 mezglus saitei, mums kaut kā jāpaziņo arī utilītai ping IPv6, kuru interfeisu izmantot.
Saskarņu definēšana — komandrindas opcija
Kā mēs jau redzējām, visu mezglu multiraides adrese, kuru vēlamies izmantot, ir − ff02::1 - nesniedz nekādu informāciju par to, ar kuru saskarni nosūtīt un saņemt ICMPv6 atbalss pieprasījumu un atbalss atbildes paketes.
Tātad, kā norādīt interfeisu, kas jāizmanto multiraides adrešu telpai vai unicast Link-Local adrešu telpai?
Pirmais un acīmredzamākais veids ir nodrošināt to kā parametru lietojumprogrammai, kuru mēs izmantojam.
Par lietderību ping mēs to nodrošinām, izmantojot opciju -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 ~]$Izmantojot šo visu mezglu multiraides ping, mēs saņēmām atbildes no 6 IPv6 mezgliem. Atbildes tika saņemtas no Link-Local IPv6 mezglu adresēm, sākot ar prefiksu fe80::/10.
Ka ping neturpina sūtīt ICMPv6 atbalss pieprasījumus bezgalīgi, līdz mēs to pārtraucam, mēs parasti norādām nosūtāmo pakešu skaitu, izmantojot opciju -c. Tomēr tas arī neļauj pingam pieņemt un parādīt vairāk nekā vienu ICMPv6 atbalss atbildi, nosūtot multiraides ICMPv6 atbalss pieprasījumu. Tā vietā mēs izmantojām opciju -w, lai norādītu, ka ping jāpabeidz pēc 1 sekundes neatkarīgi no tā, cik ICMPv6 atbalss pieprasījumu vai atbalss atbilžu tika nosūtīts vai saņemts.
Vēl viena lieta, kurai jāpievērš uzmanība, ir (DUP!) izvade uz otro un turpmākajām atbildēm. Šīs paketes tiek identificētas kā atbildes dublikāti, jo tām ir tāda pati ICMP secības vērtība kā atsevišķiem ICMPv6 atbalss pieprasījumiem, kas tika nosūtīti vispirms. Tie parādās, jo ICMPv6 multiraides atbalss pieprasījums rada vairākas atsevišķas unicast atbildes. Dublikātu skaits norādīts arī statistikas apkopojumā.
Saskarņu definēšana — zonas ID
Vēl viens veids, kā atklāt saskarni lietošanai, ir daļa no IPv6 adreses parametra.
Piemēru var redzēt ping izvadē, kur atbildīgo IPv6 saimniekdatoru adresēm ir arī sufikss %enp3s2, piemēram:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msŠī saskarņu norādīšanas metode ir formāli aprakstīta [RFC4007], "IPv6 definētās adreses arhitektūra". Lai gan tos parasti sauc par operētājsistēmas interfeisu, tie patiesībā definē kaut ko vispārīgāku — "zonu" vai "tvērumu".
Iemesls vispārīgāku zonu vai darbības jomu zonu izveidei ir tāds, ka, kā minēts [RFC4007], IPv6 mezglam var būt vairākas atšķirīgas IPv6 saskarnes, kas savienotas ar vienu un to pašu kanālu. Šīs saskarnes ir vienas zonas dalībnieki.
Jābūt iespējai grupēt vairākas saskarnes operētājsistēmas zonā; Pašlaik es nezinu, vai tas ir iespējams ar Linux vai kā to izdarīt.
Izmantojot piedēkli %<zone_id>, mēs varam noņemt komandrindas opciju -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 ~]$Saites vietējās adreses atbildes
No šī visu mezglu multiraides ping mēs saņēmām kopumā 6 unikālas atbildes.
Šīs atbildes tika saņemtas no unicast Link-Local IPv6 resursdatora adresēm. Piemēram, šeit ir pirmā atbilde:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msUnicast Link-Local IPv6 adreses ir nepieciešamas visās saskarnēs, kurās iespējots IPv6 [RFC4291], “IP 6. versijas adresēšanas arhitektūra”. Iemesls tam ir tāds, ka IPv6 mezglam vienmēr automātiski ir unicast IPv6 adrese, ko tas var vismaz izmantot, lai sazinātos ar citiem mezgliem tā tieši savienotajās saitēs. Tas ietver saziņu ar lietojumprogrammām citos saimniekdatoros, izmantojot Link-Local resursdatora adreses.
Tas vienkāršo tādu protokolu kā IPv6 Neighbor Discovery un OSPFv3 izstrādi un ieviešanu. Tas arī ļauj galalietotāju lietojumprogrammām resursdatoros sazināties pa kanālu, neprasot kanālā nekādu citu atbalstošu IPv6 infrastruktūru. Tiešai saziņai starp pievienotajiem IPv6 resursdatoriem savienojumam nav nepieciešams IPv6 maršrutētājs vai DHCPv6 serveris.
Link-Local adreses sākas ar 10 bitu prefiksu fe80, kam seko 54 nulles biti un pēc tam 64 bitu interfeisa identifikators (IID). Iepriekš minētajā pirmajā atbildē 2392:6213:a15b:66ff ir 64 bitu IID.
Looped Multicast
Pēc noklusējuma multiraides paketes tiek iekšēji atgrieztas mezglā, kas tās nosūtījis. Tas notiek gan IPv6, gan IPv4 adresēšanai.
Šīs noklusējuma darbības iemesls ir tas, ka, nosūtot multiraides paketes, var būt arī klausīšanās vietējā multiraides lietojumprogramma, kas darbojas pašā sūtītāja resursdatorā, kā arī kaut kur tīklā. Šai vietējai lietojumprogrammai ir jāsaņem arī multiraides paketes.
Mēs varam redzēt šo multiraides lokālo loku mūsu ping izvadē:
[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!)
...Pirmā un ātrākā atbilde (0,106 ms salīdzinājumā ar 0,453 ms) nāk no Link-Local adreses, kas konfigurē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 ~]$Lietderība ping nodrošina veidu, kā apspiest vietējo multiraides atgriezenisko saiti, izmantojot parametru -L. Ja mēs nosūtām visu mezglu multiraides ping ar šo karogu, atbildes ir ierobežotas ar attāliem mezgliem. Mēs nesaņemam atbildi no sūtīšanas saskarnes Link-Local adreses.
[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 saites vietējās adreses
Kā jūs varētu nojaust, unicast Link-Local adreses pašas par sevi arī nesniedz pietiekami daudz informācijas, lai norādītu, kuru saskarni izmantot, lai tās sasniegtu. Tāpat kā visu mezglu multiraides ping, mums ir jānorāda arī interfeiss kā komandrindas parametrs ping vai zonas ID ar adresi, pingot Link-Local adreses.
Šoreiz mēs varam izmantot -clai ierobežotu nosūtīto un saņemto pakešu un atbilžu skaitu ping, jo mēs veicam unicast 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 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 ~]$Vai pārbaudīt (visas) citas IPv6 adreses?
Šajā rakstā mēs redzējām, kā ping visiem IPv6 mezgliem kanālā, izmantojot visu mezglu multiraides IPv6 adresi. ff02::1. Mēs arī redzējām, kā norādīt, kuru saskarni izmantot ar visu mezglu multiraides IPv6 adresi, jo pati adrese nevar sniegt šo informāciju. Mēs izmantojām vai nu komandrindas opciju ping, vai norādījis interfeisu, izmantojot sufiksu %<zone_id>.
Pēc tam mēs uzzinājām par unicast Link-Local adresēm, kuras tiek izmantotas, lai atbildētu uz visu mezglu multiraides ICMPv6 atbalss pieprasījumiem.
Mēs arī redzējām, kā multiraides paketes pēc noklusējuma tiek atgrieztas sūtīšanas mezglā un kā to atspējot utilītai ping.
Visbeidzot, mēs piekodinājām vienu Link-Local adresi, izmantojot sufiksu %<zone_id>, jo pašas Link-Local adreses arī nesniedz informāciju par izejošo interfeisu.
Tātad, kā ar ping visiem pārējiem mezgliem un iegūt to globālās unicast adreses (GUA) (tas ir, publiskās adreses internetā) vai unikālās vietējās unicast adreses (ULA)? Mēs to aplūkosim nākamajā emuāra ierakstā.
Tas ir viss.
Vairāk par mūsu kursu varat uzzināt vietnē.
Avots: www.habr.com
