Der er kun få dage tilbage til starten af en ny kursusstrøm fra OTUS. I denne forbindelse vil vi gerne dele en oversættelse af nyttigt materiale om emnet med dig.
En række blogindlæg om IPv6 Ping (ICMPv6 Echo Request/Echo Reply) fejlfindingstips og tricks
Bemærk venligst, at jeg bruger Linux (specifikt Fedora 31), men ping-kommandosyntaksen for andre operativsystemer skulle forhåbentlig være meget ens.
Ping alle IPv6-noder på en kanal
Det første og nemmeste tip er at pinge alle IPv6-noder på kanalen.
IPv6 bruger multicast-adresser til alle typer en-til-mange-kommunikation. Der er ingen broadcast IPv6-adresser. Dette adskiller IPv6 fra IPv4, hvor der er flere typer broadcast-adresser, såsom "limited broadcast"-adressen 255.255.255.255 [RFC1122].
Der er dog en "all-nodes multicast" IPv6-adresse, så vi vil bruge den til at pinge alle IPv6-noder på linket. (En "broadcast"-adresse er faktisk bare en specielt navngivet multicast-adresse, som er en multicast-gruppe, der omfatter alle noder. Bemærk, at f.eks. "gruppe"- eller multicast-adressebit er slået til i Ethernet-broadcast-adresser på datalinklaget.)
All-nodes multicast IPv6-adresse for kanalen: ff02::1. ff angiver en multicast IPv6-adresse. Den næste 0 er den del af flaget med unset bits.
Næste 2 definerer omfanget af en multicast-gruppe. I modsætning til IPv4 multicast-adresser har IPv6 multicast-adresser et omfang. Omfangsværdien angiver den del af netværket, som multicast-pakken må videresendes over. Når en pakke når grænsen for det angivne omfang, skal pakken kasseres, uanset om dens Hop Count-felt er ikke-nul. Hvis hoptælleren når nul, før den specificerede multicast-gruppegrænse nås, nulstilles den naturligvis også straks. Her er den komplette liste over IPv6 multicast scopes.
Endelig ::1 Angiver en multicast-gruppe med alle noder.
Om adressen ff02::1 Det skal bemærkes, at det er tvetydigt. På en IPv6-node med flere grænseflader, såsom en router eller en multihomed-vært, er adressen ff02::1 Der er intet at specificere, hvilken grænseflade der skal sendes ICMPv6 ekko-anmodninger til eller forvente ICMPv6 ekko-svar, når de ankommer. ff02::1 er gyldig og kan bruges på alle de grænseflader og kanaler, der er knyttet til multi-interface noden.
Så når vi pinger alle IPv6-noder på kanalen, skal vi også på en eller anden måde fortælle værktøjet ping til IPv6, hvilket interface der skal bruges.
Definition af grænseflader - Kommandolinjevalg
Som vi allerede har set, er den all-nodes multicast-adresse, vi ønsker at bruge ff02::1 - giver ingen information om, hvilken grænseflade der skal sendes og modtages ICMPv6 ekkoanmodnings- og ekkosvarpakker på.
Så hvordan specificerer vi den grænseflade, der skal bruges til multicast-adresserummet eller unicast Link-Local-adresser?
Den første og mest oplagte måde er at give det som en parameter til den applikation, vi bruger.
For brugsen ping vi giver det gennem muligheden -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 ~]$Med denne all-nodes multicast ping fik vi svar fra 6 IPv6 noder. Svar kom fra node Link-Local IPv6-adresser, der starter med præfikset fe80::/10.
Det ping for ikke at blive ved med at sende ICMPv6 ekko-anmodninger på ubestemt tid, indtil vi afbryder det, angiver vi normalt antallet af pakker, der skal sendes via -c-indstillingen. Dette forhindrer dog også ping i at modtage og vise mere end ét ICMPv6 ekkosvar, når der sendes en ICMPv6 ekkoanmodningsmulticast. I stedet brugte vi muligheden -w til at specificere, at ping skulle afsluttes efter 1 sekund, uanset hvor mange ICMPv6 ekko-anmodninger eller ekkosvar, der blev sendt eller modtaget.
En anden ting at bemærke er (DUP!) konklusion på det andet og efterfølgende svar. Disse pakker identificeres som duplikerede svar, fordi de har den samme ICMP-sekvensværdi som de individuelle ICMPv6-ekkoanmodninger, der blev sendt i første omgang. De vises, fordi en ICMPv6 multicast ekko-anmodning resulterer i flere unicast-svar. Antallet af dubletter er også angivet i statistikoversigten.
Definition af grænseflader - Zone ID
En anden måde at eksponere en grænseflade til brug på er som en del af en IPv6-adresseparameter.
Vi kan se et eksempel på dette i ping-outputtet, hvor adresserne på de reagerende IPv6-værter også har suffikset %enp3s2, for eksempel:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msDenne metode til at specificere grænseflader er formelt beskrevet i [RFC4007], "IPv6 Assigned Address Architecture". Selvom de almindeligvis omtales som en operativsystemgrænseflade, definerer de faktisk noget mere generelt - en "zone" eller "omfang".
Grunden til at have mere generelle zoner eller scope-zoner er, at som nævnt i [RFC4007], kan en IPv6-node have flere forskellige IPv6-grænseflader forbundet til det samme link. Disse grænseflader er medlemmer af samme zone.
Det bør være muligt at gruppere flere grænseflader inden for en zone under operativsystemet; I øjeblikket ved jeg ikke, om dette er muligt under Linux, og hvordan man gør det.
Brug af suffikset %<zone_id>, kan vi fjerne kommandolinjeparameteren -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 ~]$Link-lokale adressesvar
Fra dette all-nodes multicast-ping modtog vi i alt 6 unikke svar.
Disse svar kom fra unicast Link-Local-adresser på IPv6-noder. For eksempel, her er det første svar:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msUnicast Link-Local IPv6-adresser er påkrævet på alle IPv6-kompatible grænseflader [RFC4291], "IP Version 6 Addressing Architecture". Grunden til dette er, at en IPv6-node altid automatisk har en unicast IPv6-adresse, som den kan bruge, i det mindste til at kommunikere med andre noder på sine direkte forbundne links. Dette inkluderer kommunikation med applikationer på andre værter via værternes Link-Local-adresser.
Dette forenkler designet og implementeringen af protokoller som IPv6 Neighbour Discovery og OSPFv3. Det giver også slutbrugerapplikationer på værter mulighed for at kommunikere over linket uden at kræve anden IPv6-understøttende infrastruktur på linket. Direkte kommunikation mellem tilsluttede IPv6-værter kræver ikke en IPv6-router eller DHCPv6-server i forbindelsen.
Link-Local-adresser begynder med et 10-bit præfiks fe80, efterfulgt af 54 nul bit og derefter en 64-bit interface identifier (IID). I det første svar ovenfor 2392:6213:a15b:66ff — er et 64-bit IID.
Looped Multicast
Som standard returneres multicast-pakker internt til den node, der sender dem. Dette sker for både IPv6- og IPv4-adressering.
Årsagen til denne standardadfærd er, at når der sendes multicast-pakker, kan der også være en lyttende lokal multicast-applikation, der kører på selve afsenderværten såvel som et andet sted på netværket. Denne lokale applikation skal også modtage multicast-pakker.
Vi kan se denne multicast-lokalløkke i vores ping-output:
[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!)
...Det første og hurtigste svar (0,106ms sammenlignet med 0,453ms) kommer fra den Link-Local-adresse, der er konfigureret på selve grænsefladen enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Hjælpeprogram ping giver en måde at undertrykke lokal multicast-feedback ved hjælp af parameteren -L. Hvis vi sender et multicast-ping med alle noder med dette flag, er svarene begrænset til eksterne noder. Vi modtager ikke svar fra afsendergrænsefladens Link-Local-adresse.
[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-lokale adresser
Som du måske kan gætte, giver unicast Link-Local-adresser i sig selv heller ikke nok information til at angive, hvilken grænseflade der skal bruges til at nå dem. Som med all-nodes multicast-ping, skal vi også angive grænsefladen som en kommandolinjeparameter. ping eller zone-id med adresse ved ping af Link-Local-adresser.
Denne gang kan vi bruge -cat begrænse antallet af pakker og svar, der sendes og modtages ping, da vi udfører 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 ~]$Ping (alle) andre IPv6-adresser?
I denne artikel så vi, hvordan man pinger alle IPv6-noder på en kanal ved hjælp af all-nodes multicast IPv6-adressen. ff02::1. Vi så også, hvordan man specificerer, hvilken grænseflade der skal bruges med en all-nodes multicast IPv6-adresse, da adressen i sig selv ikke kan give disse oplysninger. Vi brugte enten kommandolinjeparameteren ping, eller specificeret grænsefladen via et suffiks %<zone_id>.
Vi lærte derefter om unicast Link-Local-adresser, som er de adresser, der bruges til at svare på ICMPv6 all-nodes multicast ekko-anmodninger.
Vi så også, hvordan multicast-pakker returneres til afsendernoden som standard, og hvordan man deaktiverer dette for værktøjet. ping.
Til sidst pingede vi en enkelt Link-Local-adresse ved hjælp af suffikset %<zone_id>, da Link-Local-adresser i sig selv heller ikke giver information om den udgående grænseflade.
Så hvad med at pinge alle andre noder og få deres globale unicast-adresser (GUA'er) (dvs. deres offentligt tilgængelige adresser på internettet) eller deres unikke lokale unicast-adresser (ULA'er)? Det vil vi se på i næste blogindlæg.
Det er alt sammen.
Du kan få mere at vide om vores kursus på.
Kilde: www.habr.com
