Nokkrir dagar eru þar til nýtt flæði hefst á hraðanum frá OTUS. Í þessu sambandi viljum við deila með þér þýðingu á gagnlegu efni um efnið.
Röð af bloggfærslum um ráð og brellur til að leysa IPv6 ping vandamál (ICMPv6 Echo Request/Echo Reply)
Vinsamlegast athugaðu að ég er að nota Linux (sérstaklega Fedora 31), en setningafræði ping skipana fyrir önnur stýrikerfi ætti vonandi að vera mjög svipuð.
Pinga alla IPv6 hnúta á rás
Fyrsta og einfaldasta ráðið er að pinga alla IPv6 hnúta á hlekknum.
IPv6 notar fjölvarpsvistföng fyrir allar gerðir ein-til-margra samskipta. Það eru engin útsending (eða útsending) IPv6 vistföng. Þetta aðgreinir IPv6 frá IPv4, þar sem það eru nokkrar gerðir af útsendingarvistföngum, til dæmis, „takmarkaður útsending“ vistfangið 255.255.255.255 [RFC1122].
Hins vegar er til „all-nodes multicast“ IPv6 vistfang, svo við munum nota það til að pinga alla IPv6 hnúta á hlekknum. ("útsendingar" vistfang er í raun bara sérnefnt fjölvarpsvistfang, sem er fjölvarpshópur sem inniheldur alla hnúta. Athugaðu að til dæmis er kveikt á "hóp" eða fjölvarpsvistfangi í Ethernet útsendingarvistföngum á hlekkjalagið ).
All-nodes multicast IPv6 vistfang fyrir rásina: ff02::1. ff táknar fjölvarps IPv6 vistfang. Næsta 0 er hluti fánans með óstilltum bitum.
Nánar 2 skilgreinir svæði fjölvarpshóps. Ólíkt fjölvarps IPv4 vistföngum hafa fjölvarps IPv6 vistföng umfang. Umfangsgildið gefur til kynna þann hluta netsins sem leyfilegt er að senda fjölvarpspakka yfir. Þegar pakki nær mörkum tilgreinds umfangs verður að sleppa pakkanum, óháð því hvort Hop Count reiturinn hans er ekki núll. Auðvitað, ef hopptalningin nær núlli áður en tilgreindum fjölvarpshópsmörkum er náð, er það líka strax endurstillt. Hér er heill listi yfir IPv6 fjölvarpssvið.
Að lokum er ::1 tilgreinir fjölvarpshóp með öllum hnútum.
Um heimilisfangið ff02::1 Það skal tekið fram að það er óljóst. Á IPv6 hýsil með mörgum viðmótum, svo sem beini eða multihomed hýsil, heimilisfangið ff02::1 það er ekkert þar sem þú getur tilgreint hvaða viðmót á að senda ICMPv6 echo beiðnir til eða búast við að fá ICMPv6 echo svör þegar þær berast. ff02::1 er gilt og hægt að nota á hvaða viðmóti og rás sem er sem er tengd við fjölviðmótshnútinn.
Svo þegar við pingum alla IPv6 hnúta á hlekk, þurfum við einhvern veginn líka að segja tólinu frá ping fyrir IPv6, hvaða viðmót á að nota.
Skilgreina tengi - Skipanalínuvalkostur
Eins og við höfum þegar séð er fjölvarpsnetfangið með öllum hnútum sem við viljum nota - ff02::1 - veitir engar upplýsingar um hvaða viðmót á að senda og taka á móti ICMPv6 bergmálsbeiðni og bergmálssvarspökkum.
Svo, hvernig tilgreinum við viðmótið sem á að nota fyrir fjölvarps heimilisfangsrýmið eða unicast Link-Local heimilisfangrýmið?
Fyrsta og augljósasta leiðin er að gefa það upp sem færibreytu fyrir forritið sem við erum að nota.
Fyrir gagnsemi ping við veitum það í gegnum valmöguleikann -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 ~]$Með því að nota þetta all-nodes multicast ping fengum við svör frá 6 IPv6 hnútum. Svör komu frá Link-Local IPv6 hnút vistföngum, byrjað á forskeytinu fe80::/10.
Það ping heldur ekki áfram að senda ICMPv6 echo beiðnir endalaust fyrr en við truflum það, við tilgreinum venjulega fjölda pakka sem á að senda með -c valkostinum. Hins vegar kemur þetta einnig í veg fyrir að ping samþykki og birti fleiri en eitt ICMPv6 bergmálssvar þegar ICMPv6 bergmálsbeiðni er send með fjölvarpi. Í staðinn notuðum við -w valkostinn til að tilgreina að ping ætti að ljúka eftir 1 sekúndu, sama hversu margar ICMPv6 bergmálsbeiðnir eða bergmálssvör voru send eða móttekin.
Annað sem þarf að borga eftirtekt til er (DUP!) úttak á seinni og síðari svörum. Þessir pakkar eru auðkenndir sem tvítekin svör vegna þess að þeir hafa sama ICMP röð gildi og einstakar ICMPv6 bergmálsbeiðnir sem voru sendar í fyrsta lagi. Þau birtast vegna þess að ICMPv6 fjölvarps bergmálsbeiðni leiðir til margra einstakra einvarpssvara. Fjöldi afrita er einnig tilgreindur í tölfræðiyfirlitinu.
Skilgreina tengi - Svæðisauðkenni
Önnur leið til að afhjúpa viðmót til notkunar er sem hluti af IPv6 vistfangabreytu.
Við getum séð dæmi um þetta í ping-úttakinu, þar sem heimilisföng IPv6 gestgjafanna sem svara hafa einnig viðskeyti %enp3s2, til dæmis:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msÞessari aðferð til að tilgreina viðmót er formlega lýst í [RFC4007], "IPv6 Defined Address Architecture." Þrátt fyrir að þau séu venjulega kölluð stýrikerfisviðmót, skilgreina þau í raun eitthvað almennara - „svæði“ eða „umfang“.
Ástæðan fyrir því að hafa almennari svæði eða umfangssvæði er sú að, eins og nefnt er í [RFC4007], getur IPv6 hnút haft nokkur mismunandi IPv6 tengi tengd sömu rás. Þessi tengi eru meðlimir á sama svæði.
Það ætti að vera hægt að flokka mörg viðmót innan svæðis undir stýrikerfinu; Eins og er veit ég ekki hvort þetta er hægt undir Linux eða hvernig á að gera það.
Með því að nota viðskeyti %<zone_id>, getum við fjarlægt skipanalínuvalkostinn -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 ~]$Svör við tengil-staðbundið heimilisfang
Frá þessu all-nodes multicast ping fengum við alls 6 einstök svör.
Þessi svör komu frá unicast Link-Local IPv6 hýsilföngum. Til dæmis, hér er fyrsta svarið:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msUnicast Link-Local IPv6 vistföng eru nauðsynleg fyrir öll IPv6-virk viðmót [RFC4291], „IP Version 6 Addressing Architecture“. Ástæðan fyrir þessu er sú að IPv6 hnútur hefur alltaf sjálfkrafa unicast IPv6 vistfang, sem hann getur að minnsta kosti notað til að hafa samskipti við aðra hnúta á beint tengdum hlekkjum sínum. Þetta felur í sér samskipti við forrit á öðrum gestgjöfum í gegnum Link-Local gestgjafanetföng.
Þetta einfaldar hönnun og útfærslu á samskiptareglum eins og IPv6 Neighbor Discovery og OSPFv3. Það gerir einnig notendaforritum á gestgjöfum kleift að hafa samskipti yfir rásina án þess að krefjast annarra stuðnings IPv6 innviða á rásinni. Bein samskipti milli tengdra IPv6 gestgjafa þurfa ekki IPv6 beini eða DHCPv6 netþjón á tengingunni.
Link-Local vistföng byrja með 10 bita forskeyti fe80, fylgt eftir með 54 núllbitum og síðan 64 bita tengi auðkenni (IID). Í fyrra svari að ofan 2392:6213:a15b:66ff er 64 bita IID.
Looped Multicast
Sjálfgefið er að fjölvarpspökkum er skilað innbyrðis í hnútinn sem sendi þá. Þetta gerist fyrir bæði IPv6 og IPv4 vistföng.
Ástæðan fyrir þessari sjálfgefna hegðun er sú að þegar fjölvarpspakkar eru sendir getur líka verið að hlustandi staðbundið fjölvarpsforrit sé keyrt á sendihýslinum sjálfum, sem og einhvers staðar á netinu. Þetta staðbundna forrit verður einnig að taka á móti fjölvarpspökkum.
Við getum séð þessa fjölvarpsheimtaug í ping-úttakinu okkar:
[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!)
...Fyrsta og hraðasta svarið (0,106 ms samanborið við 0,453 ms) kemur frá Link-Local heimilisfanginu sem er stillt á viðmótið sjálft enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Gagnsemi ping býður upp á leið til að bæla niður staðbundna fjölvarpsendurgjöf með því að nota færibreytuna -L. Ef við sendum all-nodes multicast ping með þessum fána, þá eru svörin takmörkuð við ytri hnúta. Við fáum ekki svar frá Link-Local heimilisfangi sendiviðmótsins.
[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-Local Heimilisföng
Eins og þú gætir giska á, veita unicast Link-Local vistföng ein og sér ekki nægar upplýsingar til að gefa til kynna hvaða viðmót á að nota til að ná til þeirra. Eins og með all-nodes multicast ping, þurfum við líka að tilgreina viðmótið sem skipanalínubreytu ping eða svæðisauðkenni með heimilisfangi þegar smellt er á Link-Local netföng.
Þennan tíma getum við notað -cað takmarka fjölda pakka og svara sem eru send og móttekin ping, þar sem við erum að framkvæma 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 ~]$Pinga (öll) önnur IPv6 vistföng?
Í þessari grein sáum við hvernig á að pinga alla IPv6 hnúta á rás með því að nota all-nodes multicast IPv6 vistfang ff02::1. Við sáum líka hvernig á að tilgreina hvaða viðmót á að nota með IPv6 vistfangi með fjölútsendingu í öllum hnútum, þar sem heimilisfangið sjálft getur ekki veitt þessar upplýsingar. Við notuðum annað hvort skipanalínuvalkostinn ping, eða tilgreindu viðmótið með því að nota viðskeytið %<zone_id>.
Síðan lærðum við um unicast Link-Local vistföng, sem eru heimilisföng sem notuð eru til að bregðast við fjölvarps ICMPv6 bergmálsbeiðnum með öllum hnútum.
Við sáum líka hvernig fjölvarpspökkum er sjálfgefið skilað í sendingarhnútinn og hvernig á að slökkva á þessu fyrir tólið ping.
Að lokum pinguðum við einu Link-Local heimilisfangi með því að nota viðskeytið %<zone_id>, þar sem Link-Local heimilisföng sjálf veita heldur ekki upplýsingar um útsendingarviðmótið.
Svo hvað með að smella á alla hina hnútana og fá alþjóðlegt unicast vistföng þeirra (GUAs) (þ.e. almannaföng þeirra á internetinu) eða einstök staðbundin unicast vistföng (ULAs)? Við skoðum þetta í næstu bloggfærslu.
Það er allt og sumt.
Þú getur fengið frekari upplýsingar um námskeiðið okkar á.
Heimild: www.habr.com