Disa të mbetura deri në fillimin e raundit të ri të kursit nga OTUS. Në lidhje me këtë, duam të ndajmë me ju përkthimin e materialeve të dobishme mbi temën.
Një seri artikujsh në blog, e kushtuar këshillave dhe rekomandimeve për zgjidhjen e problemeve të lidhura me pingun IPv6 (ICMPv6 Echo Request/Echo Reply)
Vini re se unë po përdor Linux (sidomos, Fedora 31), megjithatë sintaksa e komandës ping për sistemet operative të tjera, shpresoj, duhet të jetë shumë e ngjashme.
Ping i të gjithë nodëve IPv6 në kanal
Këshilli i parë dhe më i thjeshtë — pingoni të gjitha nodet IPv6 në kanal.
IPv6 përdor adresa multicast për të gjitha llojet e lidhjeve «një në shumë». Nuk ka adresa bllokuese (apo broadcast) IPv6. Kjo e dallon IPv6 nga IPv4, ku ekzistojnë disa lloje adresash bllokuese, për shembull, adresa «limited broadcast» 255.255.255.255 [RFC1122].
Megjithatë, ekziston një adresë IPv6 multicast «all-nodes» (multicast për të gjithë nodet), ndaj do ta përdorim atë për të pinguar të gjitha nodet IPv6 në kanal. (Adresa «bllokuese» në të vërtetë është thjesht një adresë multicast e emëruar posaçërisht, e cila është një grup i shpërndarjes multiadresa që përfshin të gjitha nodet. Vini re se, për shembull, biti i «grupit» ose adresa e multicast është përfshirë në adresat bllokuese të Ethernet në nivelin e kanalit).
Adresa multicast IPv6 për të gjitha nodet në kanal: ff02::1. ff tregon adresën multicast IPv6. Ndonjëherë 0 — është pjesa e flamurit me bitet jo të vendosura.
Tjetër 2 definon fushën e grupit multicast. Ndryshe nga adresat multicast IPv4, adresat multicast IPv6 kanë një fushë (scope). Vlera e fushës tregon pjesën e rrjetit për të cilën lejohet bëja e frymës multicast. Sa herë që paketa arrin kufirin e fushës të specifikuar, paketa duhet të hidhet poshtë, pavarësisht nëse fusha e numrit të kalimeve (Hop Count) është e ndryshme nga zero. Natyrisht, nëse numri i kalimeve arrin zero përpara se të arrijë kufirin e caktuar të grupit multicast, ajo gjithashtu hidhet menjëherë. Këtu është lista e plotë e fushave multicast IPv6.
Finally, ::1 tregon grupin multicast all-nodes.
Rreth adresës ff02::1 duhet të vërehet se është e paqartë. Në një nod IPv6 me disa interfeca, siç është një router ose një host multi-rete, adresa ff02::1 nuk ka asgjë që të tregon se në cilin interface dërgohen kërkesat për echo ICMPv6 ose presim për marrjen e përgjigjeve për echo ICMPv6, kur ato vijnë. ff02::1 është e vlefshme dhe mund të përdoret në çdo nga interface-t dhe kanalet e lidhura me nyjën me shumë interface.
Prandaj, kur ne pingojmë të gjitha nyjat IPv6 në kanal, na nevojitet një mënyrë për të komunikuar gjithashtu me utilitarin ping për IPv6, se cili interface duam të përdorim.
Përcaktimi i interface-ve është një parametr i linjës së komandës.
Siç kemi parë, adresa multicast all-nodes që dëshirojmë të përdorim — ff02::1 — nuk ofron asnjë informacion në lidhje me atë se në cilin interface dërgohen dhe pranohen paketat për echo dhe përgjigjet për echo ICMPv6.
Prandaj, si mund të specifikojmë interface-in që do të përdoret për hapësirat e adresave multicast ose adresave unicast Link-Local?
Mënyra e parë dhe më e qartë është ta japim atë si një parametr për aplikacionin që po përdorim.
Për utilitarin ping ne ofrojmë atë përmes opsionit -I.
[mark@opy ~]$ ping -w 1 -I enp3s2 ff02::1
ping: Warning: address source mund të zgjidhet në pajisje tjetër përveç: enp3s2
PING ff02::1(ff02::1) nga :: enp3s2: 56 byte të dhënash
64 byte nga fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 kohë=0.438 ms
64 byte nga fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 kohë=0.589 ms (DUP!)
64 byte nga fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 kohë=5.15 ms (DUP!)
64 byte nga fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 kohë=58.0 ms (DUP!)
64 byte nga fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 kohë=62.3 ms (DUP!)
64 byte nga fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 kohë=62.8 ms (DUP!)
--- statistikët e ping-ut ff02::1 ---
1 paketë e dërguar, 1 e pranuar, +5 dublikat, 0% humbje pakete, kohë 0ms
rtt min/mesatar/max/mdev = 0.438/31.544/62.786/29.566 ms
[mark@opy ~]$Me këtë ping all-nodes multicast, ne morëm përgjigje nga 6 nyja IPv6. Përgjigjet erdhën nga adresat Link-Local IPv6 të nyjës që fillojnë me prefiksin fe80::/10.
Për ping nuk vazhdoi të dërgojë pafundësisht kërkesa echo ICMPv6 derisa të ndërprejmë atë, ne zakonisht e specifikojmë numrin e paketave për t'u dërguar përmes opsionit -c. Megjithatë, kjo nuk lejon ping-un të pranojë dhe tregojë më shumë se një përgjigje echo ICMPv6 gjatë dërgimit të kërkesave multicast echo ICMPv6. Në vend të kësaj, përdorim parametrin -w, që tregon se ping duhet të përfundojë pas 1 sekondi, pavarësisht se sa kërkesa echo ose përgjigje echo ICMPv6 janë dërguar ose pranuar.
Një tjetër gjë për t'u vënë re është (DUP!) rezultati në përgjigjet e dytë dhe të mëvonshme. Këto paketa identifikohen si përgjigje të dyfishta, pasi kanë të njëjtin vlerësim të sekuencës ICMP si kërkesat individuale ICMPv6, të cilat janë dërguar fillimisht. Ato shfaqen sepse kërkesa për multikast ICMPv6 çon në disa përgjigje të veçanta unicast. Numri i dyfisht është gjithashtu i shënuar në përmbledhjen e statistikave.
Përcaktimi i interface-ve — Zona ID
Një tjetër mënyrë për të ofruar një interface për përdorim është një pjesë e parametrave të adresës IPv6.
Ne mund të vëzhgojmë një shembull të këtij në rezultatin e ping, ku adresat e nyjeve IPv6 që përgjigjen gjithashtu kanë sufiksin %enp3s2, për shembull:
64 bytes nga fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 kohë=0.438 msKjo mënyrë e caktimit të interface-ve është formalizuar në [RFC4007], "Arkitektura me adresa të caktuara IPv6". Ndërsa zakonisht quhen interface të sistemit operativ, ata në të vërtetë përcaktojnë diçka më të përgjithshme — "zona" ose "fushë veprimi".
Arsyeja e pranisë së zonave më të përgjithshme ose zonave të fushës është se, siç përmendet në [RFC4007], një nyje IPv6 mund të ketë disa interface të ndryshme IPv6 të lidhura në të njëjtin kanal. Këto interface janë anëtarë të një zone.
Duhet të jetë e mundur të gruposh disa interface në brendësi të zonës nën sistemin operativ; për momentin, nuk e di nëse kjo është e mundur në Linux dhe si mund të bëhet.
Duke përdorur sufiksin %, ne mund të eliminojmë parametrin e linjës së komandave -I ping.
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 bytes të dhënash
64 bytes nga fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 kohë=0.106 ms
64 bytes nga fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 kohë=0.453 ms (DUP!)
64 bytes nga fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 kohë=0.606 ms (DUP!)
64 bytes nga fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 kohë=6.23 ms (DUP!)
64 bytes nga fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 kohë=157 ms (DUP!)
64 bytes nga fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 kohë=159 ms (DUP!)
64 bytes nga fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 kohë=161 ms (DUP!)
64 bytes nga fe80::23d:e8ff:feec:958c%enp3s2: icmp_seq=1 ttl=64 kohë=179 ms (DUP!)
--- statistikën e ping-ut të ff02::1%enp3s2 ---
1 paketa e dërguar, 1 e pranuar, +7 dyfishime, 0% humbje pakete, kohë 0ms
rtt min/mesatare/maksimale/mdev = 0.106/82.858/179.216/81.281 ms
[mark@opy ~]$Përgjigjet nga adresat Link-Local
Nga kjo ping-all-nodes multicast ne morëm gjithsej 6 përgjigje unike.
Këto përgjigje erdhën nga adresat unicast Link-Local të nyjeve IPv6. Për shembull, ja përgjigja e parë:
64 bytes nga fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 kohë=0.106 msTë gjitha interfaces me mbështetje për IPv6 kërkojnë adresa Link-Local IPv6 [RFC4291], "Arkitektura e adresimit të IP version 6". Arsyeja për këtë është se një nod IPv6 gjithmonë ka automatikisht një adresë unicast IPv6 që mund ta përdorë, të paktën për komunikim me nodet e tjera përmes kanaleve të lidhura drejtpërdrejt. Kjo përfshin komunikimin me aplikacionet e hosteve të tjera përmes adresave Link-Local të hosteve.
Kjo thjeshton zhvillimin dhe implementimin e protokolleve, të tilla si IPv6 Neighbor Discovery dhe OSPFv3. Kjo gjithashtu i lejon aplikacioneve të përdoruesve përfundimtarë në hoste të ndajnë të dhëna përmes kanalit, pa kërkuar ndonjë infrastrukturë mbështetëse tjetër IPv6 në kanal. Për lidhje të drejtpërdrejta midis hosteve të lidhura, nuk kërkohet një router IPv6 ose server DHCPv6 në lidhje.
Adresat Link-Local fillojnë me një prefiks 10-bitësh fe80, pasuar nga 54 bita zero, dhe më pas një identifikues interfesi 64-bit (IID). Në përgjigjen e parë të dhënë më lart 2392:6213:a15b:66ff — është një IID 64-bit.
Multicast i Cikluar
Me përjashtim, paketat multicast kthehen brenda në nodin që i dërgon ato. Kjo ndodh për të dy adresimet IPv6 dhe IPv4.
Arsyeja për këtë sjellje të defoltit është se kur dërgohen paketa multicast, gjithashtu mund të ketë një aplikacion lokal multicast që po dëgjon në vetë hostin dërgues, ashtu si dhe diku në rrjet. Ky aplikacion lokal gjithashtu duhet të marrë paketat multicast.
Ne mund ta shohim këtë cikël lokal multicast në rezultatin tonë të 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!)
...Përgjigjja e parë dhe më e shpejtë (0,106 ms krahasuar me 0,453 ms) vjen nga adresa Link-Local e caktuar në vetë interfesin enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Mjeti ping ofron një mënyrë për të shtypur ndarjen lokale të mbështetjes së përhapjes multicast me anë të parametrave -L. Nëse ne dërgojmë një ping me multicast të të gjithë nodet me këtë flamur, atëherë përgjigjet kufizohen në nodet e largëta. Ne nuk marrim përgjigje nga adresa Link-Local e interfesit dërgues.
[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 i Adresës Link-Local
Siç mund ta hamendësoni, adresat unicast Link-Local vetvetiu nuk ofrojnë mjaft informacione për të treguar se cili ndërfaqe duhet të përdoret për t'i arritur ato. Siç ndodh me pingun all-nodes multicast, ne gjithashtu duhet të specifikojmë ndërfaqen si një parametër për komandën në linjë. ping apo ID-në e zonës me adresën gjatë pingimit të adresave Link-Local.
Këtë herë ne mund të përdorim -c, për të kufizuar numrin e pakove dhe përgjigjeve të dërguara dhe të marra ping, teksa bëjmë ping unicast.
[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 byte të dhëna
64 byte nga fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 kohë=0.395 ms
--- statistikat e pingimit fe80::f31c:ccff:fe26:a6d9%enp3s2 ---
1 paketa e dërguar, 1 e marrë, 0% humbje pakete, kohë 0ms
rtt min/mesatar/max/mdev = 0.395/0.395/0.395/0.000 ms
[mark@opy ~]$Të pingojmë (të gjithë) adresat e tjerë IPv6?
Në këtë artikull ne kemi parë se si të pingojmë të gjitha nodet IPv6 në kanal, duke përdorur adresën all-nodes multicast IPv6. ff02::1Ne gjithashtu kemi parë se si të specifikojmë se cilën ndërfaqe të përdorim me adresën all-nodes multicast IPv6, duke pasur parasysh se adresa vetvetiu nuk mund të ofrojë këtë informacion. Ne kemi përdorur ose parametrin e komandës në linjë ping, ose kemi specifikuar ndërfaqen përmes suffix-it %.
Më pas kemi mësuar për adresat unicast Link-Local, të cilat janë adresat që përdoren për përgjigje ndaj kërkesave ICMPv6 all-nodes multicast echo.
Kemi parë gjithashtu si paketat multicast kthehen në nodin dërgues sipas parimit, dhe si ta çaktivizojmë këtë për utilitarin ping.
Më në fund, ne kemi pinguar një adresë Link-Local, duke përdorur suffix-in %, pasi adresat Link-Local vetvetiu nuk ofrojnë informacion për ndërfaqen e daljes.
Çfarë ndodh me pingun e të gjitha nodëve të tjera dhe marrjen e adresave të tyre unicast globale (GUA) (dmth. adresat e tyre publike në internet) ose adresat e tyre unicast të unikshme lokale (ULA)? Ne do të shqyrtojmë këtë në artikullin e ardhshëm të blogut.
Këtu përfundon gjithçka.
Mësoni më shumë rreth kursit tonë në.
Burimi: habr.com
