Egun batzuk falta dira erritmoan fluxu berri bat hasteko OTUSetik. Ildo horretatik, gaiari buruzko material erabilgarriaren itzulpena partekatu nahi dugu zuekin.
IPv6 ping-arazoak konpontzeko aholku eta trikimailuei buruzko blog-argitalpen sorta (ICMPv6 Echo Request/Echo Reply)
Kontuan izan Linux erabiltzen ari naizela (bereziki Fedora 31), hala ere, beste sistema eragile batzuen ping komandoaren sintaxia oso antzekoa izan beharko litzatekeela espero dugu.
Egin ping kanal batean IPv6 nodo guztiei
Lehenengo aholkua eta errazena estekaren IPv6 nodo guztiei ping egitea da.
IPv6-k multicast helbideak erabiltzen ditu bat-to-asko komunikazio mota guztietarako. Ez dago igorpen (edo igorpen) IPv6 helbiderik. Honek IPv6 eta IPv4 bereizten ditu, non hainbat igorpen-helbide mota dauden, adibidez, "difusio mugatua" helbidea 255.255.255.255 [RFC1122].
Hala ere, "nodo guztien multicast" IPv6 helbide bat dago, beraz, estekan dauden IPv6 nodo guztiei ping egiteko erabiliko dugu. ("Igorpen" helbide bat, hain zuzen ere, bereziki izendatzen den multicast helbide bat besterik ez da, hau da, nodo guztiak barne hartzen dituen multicast talde bat. Kontuan izan, adibidez, "taldea" edo multicast helbide-bita aktibatuta dagoela Ethernet difusio-helbideetan esteka geruzan. ).
Nodo guztietako multicast IPv6 helbidea kanalerako: ff02::1. ff Multicast IPv6 helbidea adierazten du. Hurrengo 0a banderaren zatia da ezarri gabeko bitekin.
Gehiago 2 Multicast talde baten eremua definitzen du. Multicast IPv4 helbideek ez bezala, multicast IPv6 helbideek esparru bat dute. Esparru-balioak sarearen zein zatitan multicast pakete bat birbidali daitekeen adierazten du. Pakete bat zehaztutako esparruaren mugara iristen denean, paketea bota egin behar da, bere Hop Count eremua nulua ez den kontuan hartu gabe. Jakina, hop-zenbaketa zerora iristen bada zehaztutako multicast taldearen mugara iritsi aurretik, berehala berrezarri da. Hona hemen IPv6 multicast esparruaren zerrenda osoa.
Azkenik, ::1 nodo guztietako multicast talde bat zehazten du.
Helbideari buruz ff02::1 Kontuan izan behar da anbiguoa dela. Interfaze anitz dituen IPv6 ostalari batean, hala nola bideratzailea edo etxe anitzeko ostalari batean, helbidea ff02::1 ez dago ezer ICMPv6 oihartzun-eskaerak zein interfazetara bidali edo ICMPv6-ko oihartzun-erantzunak iristen direnean jasotzea espero dezakezun. ff02::1 baliozkoa da eta interfaze anitzeko nodoari atxikitako edozein interfaze eta kanaletan erabil daiteke.
Beraz, esteka bateko IPv6 nodo guztiei ping-a egiten diogunean, nolabait erabilgarritasunari ere esan behar diogu ping IPv6rako, zein interfaze erabili.
Interfazeak definitzea - ββKomando-lerroko aukera
Lehen ikusi dugunez, erabili nahi dugun nodo guztien multicast helbidea - da ff02::1 - ez du informaziorik ematen ICMPv6 oihartzun eskaera eta oihartzun erantzun paketeak bidali eta jasotzeko zein interfazeari buruz.
Beraz, nola zehazten dugu multicast helbide-espaziorako edo unicast Link-Local helbide-espaziorako erabiliko den interfazea?
Lehenengo eta agerikoena erabiltzen ari garen aplikazioari parametro gisa ematea da.
Erabilgarritasunagatik ping aukeraren bidez ematen dugu -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 ~]$Nodo guztietako multicast ping hau erabiliz, 6 IPv6 nodoren erantzunak jaso ditugu. Erantzunak Link-Local IPv6 nodo helbideetatik etorri dira, aurrizkitik hasita fe80::/10.
That ping ez du ICMPv6 oihartzun eskaerak bidaltzen mugagabean eten arte, normalean -c aukeraren bidez bidali beharreko pakete kopurua zehazten dugu. Hala ere, horrek ping-ak ICMPv6 oihartzun-erantzun bat baino gehiago onartzea eta bistaratzea eragozten du ICMPv6 multicast ICMPv1 oihartzun-eskaera bat bidaltzean. Horren ordez, -w aukera erabili dugu ping segundo 6 ondoren amaitu behar dela zehazteko, ICMPvXNUMX oihartzun-eskaera edo oihartzun-erantzun zenbat bidali edo jaso diren ere.
Erreparatu beharreko beste gauza bat da (DUP!) bigarren eta ondorengo erantzunetan irteera. Pakete hauek erantzun bikoiztu gisa identifikatzen dira, lehen bidali ziren ICMPv6 oihartzun eskaera indibidualen ICMP sekuentzia balio bera dutelako. ICMPv6 multicast oihartzun-eskaerak bakarkako bakarkako erantzun anitz eragiten dituelako agertzen dira. Bikoiztuen kopurua ere adierazten da estatistiken laburpenean.
Interfazeak definitzea - ββZona ID
Erabiltzeko interfaze bat erakusteko beste modu bat IPv6 helbide-parametro baten parte da.
Honen adibide bat ping irteeran ikus dezakegu, non erantzuten duten IPv6 ostalarien helbideek atzizkia ere badute. %enp3s2, adibidez:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msInterfazeak zehazteko metodo hau formalki deskribatzen da [RFC4007], "IPv6 Defined Address Architecture". Normalean sistema eragilearen interfazea deitzen zaien arren, benetan zerbait orokorragoa definitzen dute: "zona" edo "esparrua".
Zona orokorragoak edo eremu eremuak edukitzearen arrazoia da, [RFC4007]-n aipatzen den bezala, IPv6 nodo batek hainbat IPv6 interfaze ezberdin izan ditzakeela kanal berean konektatuta. Interfaze hauek zona bereko kideak dira.
Sistema eragilearen pean eremu batean interfaze anitz multzokatzea posible izan beharko litzateke; Gaur egun ez dakit Linux-en hau posible den edo nola egin.
Atzizkia erabiliz %<zone_id>, komando lerroko aukera kendu dezakegu -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 ~]$Esteka-helbide lokalaren erantzunak
Nodo guztietako multicast ping honetatik 6 erantzun berezi jaso ditugu guztira.
Erantzun hauek unicast Link-Local IPv6 ostalariaren helbideetatik etorri dira. Adibidez, hona hemen lehen erantzuna:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msUnicast Link-Local IPv6 helbideak beharrezkoak dira IPv6 gaitutako interfaze guztietan [RFC4291], "IP Version 6 Addressing Architecture". Horren arrazoia da IPv6 nodo batek beti automatikoki duela IPv6 helbide unicast bat, eta gutxienez zuzenean konektatutako esteketako beste nodo batzuekin komunikatzeko erabil dezake. Honek beste ostalari batzuetako aplikazioekin komunikatzea barne hartzen du Link-Local ostalariaren helbideen bidez.
Honek IPv6 Neighbor Discovery eta OSPFv3 bezalako protokoloen diseinua eta ezarpena errazten du. Gainera, ostalarietako azken erabiltzaileen aplikazioak kanalaren bidez komunikatzeko aukera ematen du, kanalean onartzen duen beste IPv6 azpiegiturarik behar izan gabe. Konektatutako IPv6 ostalarien arteko komunikazio zuzenak ez du IPv6 bideratzailerik edo DHCPv6 zerbitzaririk behar konexioan.
Link-Local helbideak 10 biteko aurrizki batekin hasten dira fe80, ondoren 54 zero bit eta ondoren 64 biteko interfaze-identifikatzailea (IID). Goiko lehen erantzunean 2392:6213:a15b:66ff 64 biteko IID bat da.
Erreprodukzio-multidifusioa
Lehenespenez, multicast paketeak barrutik itzultzen dira bidali dituen nodora. Hau IPv6 eta IPv4 helbideratzeetan gertatzen da.
Portaera lehenetsi honen arrazoia da multicast paketeak bidaltzen direnean, entzuteko tokiko multicast aplikazio bat ere exekutatzen ari dela bidaltzen duen ostalarian bertan, baita sareko nonbait ere. Aplikazio lokal honek multicast paketeak ere jaso behar ditu.
Multicast tokiko begizta hau gure ping irteeran ikus dezakegu:
[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!)
...Lehenengo erantzuna eta azkarrena (0,106 ms 0,453 ms-ren aldean) interfazean bertan konfiguratutako Link-Local helbidetik dator. enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Erabilgarritasuna ping parametroa erabiliz tokiko multicast feedbacka kentzeko modu bat eskaintzen du -L. Bandera honekin nodo guztietako multicast ping bat bidaltzen badugu, erantzunak urruneko nodoetara mugatzen dira. Ez dugu erantzunik jasotzen bidalketa interfazearen Link-Local helbidetik.
[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-Helbide lokalak
Asma dezakezun bezala, unicast Link-Local helbideek berez ere ez dute informazio nahikoa ematen haietara iristeko zein interfaze erabili behar den adierazteko. Nodo guztietako multicast ping-arekin gertatzen den bezala, interfazea komando lerroko parametro gisa ere zehaztu behar dugu ping edo eremuko IDa helbidea duen Link-Local helbideei ping egitean.
Oraingoan erabil dezakegu -cbidalitako eta jasotako paketeen eta erantzunen kopurua mugatzeko ping, unicast ping egiten ari garenez.
[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 ~]$Beste IPv6 helbide batzuei ping (guztiak) egin?
Artikulu honetan, kanal bateko IPv6 nodo guztiei ping nola egin ikusi dugu nodo guztien multicast IPv6 helbide bat erabiliz. ff02::1. Nodo guztietako multicast IPv6 helbide batekin zein interfaze erabili nola zehaztu ere ikusi genuen, helbideak berak ezin baitu informazio hori eman. Komando-lerroko aukera erabili dugu ping, edo interfazea zehaztu atzizkia erabiliz %<zone_id>.
Ondoren, unicast Link-Local helbideei buruz ikasi genuen, hau da, nodo guztietako multicast ICMPv6 oihartzun eskaerei erantzuteko erabiltzen diren helbideak.
Multicast paketeak nola itzultzen diren lehenespenez bidalketa-nodora eta hau erabilgarritasunerako nola desgaitu ere ikusi genuen. ping.
Azkenik, Link-Local helbide bakar bati egin diogu ping-a atzizkia erabiliz %<zone_id>, Link-Local helbideek beraiek ere ez baitute irteerako interfazeari buruzko informaziorik ematen.
Beraz, zer gertatzen da beste nodo guztiei ping-a egin eta haien global unicast helbide (GUA) (hau da, beren helbide publikoak Interneten) edo beren tokiko unicast helbide (ULA) esklusiboak? Hurrengo blogean ikusiko dugu hau.
Hori da dena.
Gure ikastaroari buruz gehiago jakin dezakezu hemen.
Iturria: www.habr.com