Kelkaj tagoj restas ĝis la komenco de nova fluo kun la rapideco de OTUS. Ĉi-rilate ni ŝatus kunhavigi kun vi tradukon de utila materialo pri la temo.
Serio de blogaj afiŝoj pri konsiletoj kaj lertaĵoj por solvi problemojn pri IPv6-pingo (ICMPv6 Eĥo-Peto/Eĥo-Respondo)
Bonvolu noti, ke mi uzas Linukson (specife Fedora 31), tamen la sintakso de komando ping por aliaj operaciumoj espereble estu tre simila.
Pingu ĉiujn IPv6-nodojn sur kanalo
La unua kaj plej simpla konsilo estas pingi ĉiujn IPv6-nodojn sur la ligilo.
IPv6 uzas multirolantajn adresojn por ĉiuj specoj de unu-al-multaj komunikadoj. Ne estas elsendaj (aŭ elsendaj) IPv6-adresoj. Ĉi tio distingas IPv6 de IPv4, kie ekzistas pluraj specoj de elsendaj adresoj, ekzemple, la "limigita elsendo" adreso 255.255.255.255 [RFC1122].
Tamen, ekzistas "ĉiuj-nodoj multicast" IPv6 adreso, do ni uzos tion por ping ĉiuj IPv6 nodoj sur la ligo. (Adreso de "elsendo" fakte estas nur speciale nomita multielsenda adreso, kiu estas multielsenda grupo kiu inkluzivas ĉiujn nodojn. Notu ke, ekzemple, la "grupo" aŭ multielsenda adresbito estas ŝaltita en Eterretaj elsendoadresoj ĉe la ligtavolo. ).
Tutnoda multirolanta IPv6-adreso por la kanalo: ff02::1. ff indikas multrolan IPv6-adreson. La sekva 0 estas la parto de la flago kun nemetitaj bitoj.
plia 2 difinas la areon de multirolantaro. Male al multrolantaj IPv4-adresoj, multirolantaj IPv6-adresoj havas amplekson. La ampleksovaloro indikas la parton de la reto super kiu multirolanta pakaĵeto rajtas esti plusendita. Post kiam pakaĵeto atingas la limon de la specifita amplekso, la pakaĵeto devas esti faligita, sendepende de ĉu ĝia Hop Count-kampo estas nenula. Kompreneble, se la saltkalkulo atingas nulon antaŭ atingi la specifitan multirolanta gruplimon, ĝi ankaŭ estas tuj rekomencigita. Jen kompleta listo de IPv6-multirolantaro.
Fine ::1 specifas tutnodan multirolanta grupon.
Pri la adreso ff02::1 Oni notu, ke ĝi estas ambigua. Sur IPv6-gastiganto kun multoblaj interfacoj, kiel ekzemple enkursigilo aŭ multihomed gastiganto, la adreso ff02::1 estas nenio, kie vi povas specifi al kiu interfaco sendi ICMPv6-eĥajn petojn aŭ atendi ricevi ICMPv6-eĥajn respondojn kiam ili alvenos. ff02::1 validas kaj uzeblas sur iu ajn el la interfacoj kaj kanaloj ligitaj al la multi-interfaca nodo.
Do kiam ni pingas ĉiujn IPv6-nodojn sur ligilo, ni devas iel ankaŭ diri al la utileco ping por IPv6, kiun interfacon uzi.
Difinante Interfacojn - Komandlinia Opcio
Kiel ni jam vidis, la tutnoda multirolantaro, kiun ni volas uzi, estas − ff02::1 - ne provizas ajnajn informojn pri kiu interfaco sendi kaj ricevi ICMPv6-eĥopeton kaj eĥajn respondpakaĵojn.
Do, kiel ni specifu la interfacon por esti uzata por la multielsenda adresspaco aŭ unicast Link-Local adresspaco?
La unua kaj plej evidenta maniero estas provizi ĝin kiel parametron al la aplikaĵo, kiun ni uzas.
Por utileco ping ni provizas ĝin per la opcio -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 ~]$Uzante ĉi tiun tut-nodojn multirolantaron, ni ricevis respondojn de 6 IPv6-nodoj. Respondoj venis de Link-Local IPv6 nodadresoj, komencante per la prefikso fe80::/10.
ke ping ne daŭre sendas ICMPv6-eĥopetojn senfine ĝis ni interrompas ĝin, ni kutime specifas la nombron da pakaĵetoj sendi per la opcio -c. Tamen, ĉi tio ankaŭ malhelpas ping akcepti kaj montri pli ol unu ICMPv6-eĥo-respondon dum sendado de multrolanta ICMPv6-eĥopeto. Anstataŭe, ni uzis la opcion -w por specifi, ke ping finiĝos post 1 sekundo, negrave kiom da ICMPv6-eĥaj petoj aŭ eĥaj respondoj estis senditaj aŭ ricevitaj.
Alia afero atentinda estas (DUP!) eligo sur la dua kaj postaj respondoj. Tiuj pakaĵetoj estas identigitaj kiel duplikataj respondoj ĉar ili havas la saman ICMP-sekvencvaloron kiel la individuaj ICMPv6-eĥopetoj kiuj estis senditaj en la unua loko. Ili ekaperas ĉar ICMPv6-multirolanta eĥpeto rezultigas multoblajn individuajn unuelsendajn respondojn. La nombro da duplikatoj ankaŭ estas indikita en la statistika resumo.
Difinante Interfacojn - Zone ID
Alia maniero elmontri interfacon por uzo estas kiel parto de IPv6-adresparametro.
Ni povas vidi ekzemplon de tio en la ping-produktaĵo, kie la adresoj de la respondantaj IPv6-gastigantoj ankaŭ havas la sufikson %enp3s2ekzemple:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msĈi tiu metodo por specifi interfacojn estas formale priskribita en [RFC4007], "IPv6 Defined Address Architecture." Kvankam ili estas kutime nomitaj la operaciuma interfaco, ili fakte difinas ion pli ĝeneralan - "zono" aŭ "amplekso".
La kialo por havi pli ĝeneralajn zonojn aŭ amplekzonojn estas ke, kiel menciite en [RFC4007], IPv6-nodo povas havi plurajn malsamajn IPv6-interfacojn konektitajn al la sama kanalo. Ĉi tiuj interfacoj estas membroj de la sama zono.
Devus esti eble grupigi plurajn interfacojn ene de zono sub la operaciumo; Nuntempe mi ne scias ĉu tio eblas sub Linukso aŭ kiel fari ĝin.
Uzante la sufikson %<zone_id>, ni povas forigi la komandlinian opcion -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 ~]$Ligo-Lokaj Adresaj Respondoj
De ĉi tiu tutnoda multirolantaro ni ricevis entute 6 unikajn respondojn.
Ĉi tiuj respondoj venis de unicast Link-Local IPv6 gastigantadresoj. Ekzemple, jen la unua respondo:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msUnicast Link-Local IPv6-adresoj estas postulataj sur ĉiuj IPv6-ebligitaj interfacoj [RFC4291], "IP Version 6 Addressing Architecture". La kialo de ĉi tio estas, ke IPv6-nodo ĉiam aŭtomate havas unuelsantan IPv6-adreson, kiun ĝi almenaŭ povas uzi por komuniki kun aliaj nodoj sur siaj rekte ligitaj ligiloj. Ĉi tio inkluzivas komuniki kun aplikoj sur aliaj gastigantoj per Link-Lokaj gastigantadresoj.
Ĉi tio simpligas la dezajnon kaj efektivigon de protokoloj kiel IPv6 Neighbor Discovery kaj OSPFv3. Ĝi ankaŭ permesas al finuzantaj aplikoj sur gastigantoj komuniki per la kanalo sen postuli ajnan alian subtenan IPv6-infrastrukturon sur la kanalo. Rekta komunikado inter konektitaj IPv6-gastigantoj ne postulas IPv6-enkursigilon aŭ DHCPv6-servilon sur la konekto.
Link-Lokaj adresoj komenciĝas per 10-bita prefikso fe80, sekvita per 54 nul bitoj kaj tiam 64-bita interfacidentigilo (IID). En la supra unua respondo 2392:6213:a15b:66ff estas 64-bita IID.
Loop Multicast
Defaŭlte, multirolantaj pakoj estas resenditaj interne al la nodo kiu sendis ilin. Ĉi tio okazas por IPv6 kaj IPv4-adresado.
La kialo de ĉi tiu defaŭlta konduto estas, ke kiam multirolantaj pakaĵetoj estas senditaj, povas ankaŭ ekzisti aŭskultanta loka multirolanta aplikaĵo funkcianta sur la sendanta gastiganto mem, same kiel ie en la reto. Ĉi tiu loka aplikaĵo ankaŭ devas ricevi multirolantaro-pakaĵojn.
Ni povas vidi ĉi tiun multrolan lokan buklon en nia ping-produktaĵo:
[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!)
...La unua kaj plej rapida respondo (0,106 ms kompare kun 0,453 ms) venas de la Link-Local adreso agordita sur la interfaco mem enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Utileco ping provizas manieron subpremi lokajn multirolantajn religojn uzante la parametron -L. Se ni sendas tut-nodojn multirolantaron kun ĉi tiu flago, tiam respondoj estas limigitaj al foraj nodoj. Ni ne ricevas respondon de la Link-Loka adreso de la senda interfaco.
[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-Lokaj Adresoj
Kiel vi eble konjektas, unuelsendaj Link-Lokaj adresoj per si mem ankaŭ ne provizas sufiĉajn informojn por indiki kiun interfacon uzi por atingi ilin. Kiel ĉe ĉiu-nodoj multirolantaro, ni ankaŭ devas specifi la interfacon kiel komandlinian parametron ping aŭ zono ID kun adreso kiam pinglado Link-Lokaj adresoj.
Ĉi-foje ni povas uzi -climigi la nombron da pakoj kaj respondoj senditaj kaj ricevitaj ping, ĉar ni elfaras 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 ~]$Pingi (ĉiujn) aliajn IPv6-adresojn?
En ĉi tiu artikolo, ni vidis kiel pigi ĉiujn IPv6-nodojn sur kanalo uzante tut-nodojn multielsendan IPv6-adreson. ff02::1. Ni ankaŭ vidis kiel specifi kian interfacon uzi kun tutnoda multrolata IPv6-adreso, ĉar la adreso mem ne povas provizi ĉi tiujn informojn. Ni uzis aŭ la komandlinian opcion ping, aŭ specifis la interfacon uzante la sufikson %<zone_id>.
Tiam ni eksciis pri unuelsendaj Link-Lokaj adresoj, kiuj estas adresoj uzataj por respondi al ĉiunodoj multirolantaj ICMPv6-eĥopetoj.
Ni ankaŭ vidis, kiel multirolantaj pakoj estas resenditaj al la senda nodo defaŭlte kaj kiel malŝalti ĉi tion por la utileco. ping.
Fine, ni pingis ununuran Link-Lokan adreson uzante la sufikson %<zone_id>, ĉar Link-Lokaj adresoj mem ankaŭ ne provizas informojn pri la eliranta interfaco.
Do kio pri ping al ĉiuj aliaj nodoj kaj ricevi iliajn tutmondajn unuelsendajn adresojn (GUAs) (t.e., iliajn publikajn adresojn en la Interreto) aŭ iliajn unikajn lokajn unuelsendajn adresojn (ULAs)? Ni rigardos ĉi tion en la sekva blogaĵo.
Tio estas ĉio.
Vi povas ekscii pli pri nia kurso ĉe.
fonto: www.habr.com