Er zijn nog maar enkele dagen tot de start van de nieuwe lichting voor de cursus van OTUS. In dit verband willen we graag een vertaling delen van nuttig materiaal over het onderwerp.
Een serie blogartikelen gewijd aan tips en aanbevelingen voor het oplossen van problemen met IPv6-ping (ICMPv6 Echo Request/Echo Reply)
Houd er rekening mee dat ik Linux gebruik (in het bijzonder Fedora 31), maar ik hoop dat de syntaxis van het ping-commando voor andere besturingssystemen heel vergelijkbaar zal zijn.
Pingen van alle IPv6 knooppunten op de verbinding
De eerste en eenvoudigste tip is om alle IPv6-nodes op de verbinding te pingen.
IPv6 gebruikt multicast-adressen voor alle soorten 'van één naar velen' communicatie. Er bestaan geen broadcast (of breedband) IPv6-adressen. Dit onderscheidt IPv6 van IPv4, waar verschillende soorten broadcast-adressen bestaan, zoals het 'limited broadcast'-adres 255.255.255.255 [RFC1122].
Er is echter een 'all-nodes multicast' (algemene multicast) IPv6-adres, dus we zullen dit gebruiken om alle IPv6-nodes op de verbinding te pingen. (Het 'broadcast'-adres is eigenlijk gewoon een speciaal genoemd multicast-adres, dat deel uitmaakt van een multicastgroep die alle nodes omvat. Let op dat, bijvoorbeeld, het 'groep'-bit of multicast-adres is opgenomen in broadcast-adressen op Ethernet-niveau).
All-nodes multicast IPv6-adres voor de verbinding: ff02::1. ff staat voor het multicast IPv6-adres. De volgende 0 is het deel van de vlag met niet-geconfigureerde bits.
Volgende 2 bepaalt de scope van de multicastgroep. In tegenstelling tot multicast IPv4-adressen hebben multicast IPv6-adressen een scope. De scope-waarde geeft het deel van het netwerk aan waar multicast-pakketten mogen worden doorgestuurd. Zodra een pakket de grens van de opgegeven scope bereikt, moet het pakket worden weggegooid, ongeacht of het hop-count-veld nul is. Natuurlijk, als de hop-count nul bereikt voordat de opgegeven grens van de multicastgroep is bereikt, wordt het ook onmiddellijk weggegooid. Hier is de volledige lijst van multicast scope IPv6.
Ten slotte, ::1 geeft de all-nodes multicastgroep aan.
Over het adres ff02::1 moet worden opgemerkt dat het ambigu is. Op een IPv6-node met meerdere interfaces, zoals een router of een multinetwerkhost, is het adres ff02::1 Er is niets dat aangeeft op welke interface ICMPv6 echo-verzoeken moeten worden verzonden of waar we zijn om ICMPv6 echo-antwoorden te ontvangen wanneer ze binnenkomen. ff02::1 De toepassing is geldig en kan worden gebruikt op een van de interfaces en kanalen die aan een multi-interface knooppunt zijn gekoppeld.
Dus, wanneer we alle IPv6 knooppunten op de link pingen, moeten we ook op een bepaalde manier de tool informeren ping voor IPv6, welke interface we moeten gebruiken.
Interface-definitie is een opdrachtregelparameter
Zoals we al hebben gezien, het multicast-adres voor alle knooppunten dat we willen gebruiken — ff02::1 — geeft geen informatie over welke interface gebruikt moet worden om ICMPv6 echo-verzoeken en echo-antwoorden te verzenden en te ontvangen.
Dus, hoe geven we de interface op die zal worden gebruikt voor multicast-adressen of voor unicast Link-Local adressen?
De eerste en meest voor de hand liggende manier is om het als parameter te geven aan de applicatie die we gebruiken.
Voor de tool ping geven we dit door via de optie -I.
[mark@opy ~]$ ping -w 1 -I enp3s2 ff02::1
ping: Waarschuwing: bronadres kan geselecteerd worden op een ander apparaat dan: enp3s2
PING ff02::1(ff02::1) van :: enp3s2: 56 data bytes
64 bytes van fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 tijd=0.438 ms
64 bytes van fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 tijd=0.589 ms (DUP!)
64 bytes van fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 tijd=5.15 ms (DUP!)
64 bytes van fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 tijd=58.0 ms (DUP!)
64 bytes van fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 tijd=62.3 ms (DUP!)
64 bytes van fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 tijd=62.8 ms (DUP!)
--- ff02::1 pingstatistieken ---
1 pakket verzonden, 1 ontvangen, +5 duplicaten, 0% pakketverlies, tijd 0ms
rtt min/avg/max/mdev = 0.438/31.544/62.786/29.566 ms
[mark@opy ~]$Met deze all-nodes multicast ping hebben we antwoorden ontvangen van 6 IPv6 knooppunten. De antwoorden kwamen van link-lokale IPv6 adressen, beginnend met het prefix fe80::/10.
Om ping We blijven meestal geen eindeloze ICMPv6 echo-verzoeken verzenden totdat we het onderbreken; doorgaans geven we het aantal te verzenden pakketten op met de optie -c. Echter, dit zorgt er niet voor dat ping meer dan één ICMPv6 echo-antwoord accepteert en weergeeft bij het verzenden van een ICMPv6 multicast echo-verzoek. In plaats daarvan hebben we de optie -w gebruikt om aan te geven dat ping na 1 seconde moet stoppen, ongeacht hoeveel ICMPv6 echo-verzoeken of antwoorden er zijn verzonden of ontvangen.
Een andere zaak om op te letten is (DUP!) uitvoer in de tweede en volgende antwoorden. Deze pakketten worden geïdentificeerd als dubbele antwoorden omdat ze dezelfde ICMP-volgorde hebben als afzonderlijke ICMPv6-echovragen die eerst zijn verzonden. Ze verschijnen omdat multicast ICMPv6-echovragen leiden tot meerdere individuele unicast-antwoorden. Het aantal duplicaten wordt ook vermeld in de samenvatting van de statistieken.
Definitie van interfaces — Zone-ID
Een andere manier om een interface te voorzien is als onderdeel van het IPv6-adresparameters.
We kunnen een voorbeeld hiervan observeren in de pinguitvoer, waar de adressen van de reagerende IPv6-knooppunten ook een suffix hebben %enp3s2, bijvoorbeeld:
64 bytes van fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 tijd=0.438 msDeze manier van het toekennen van interfaces is formeel beschreven in [RFC4007], 'Architectuur van met adres gedefinieerd IPv6'. Hoewel ze gewoonlijk de interface van het besturingssysteem worden genoemd, definiëren ze eigenlijk iets algemeners — 'zone' of 'scopecategorie'.
De reden voor het bestaan van bredere zones of scope zones is dat, zoals vermeld in [RFC4007], een IPv6-knooppunt meerdere verschillende IPv6-interfaces kan hebben die aan dezelfde link zijn verbonden. Deze interfaces zijn leden van dezelfde zone.
Het moet mogelijk zijn meerdere interfaces binnen dezelfde zone in het besturingssysteem te groeperen; momenteel weet ik niet of dit mogelijk is op Linux en hoe dit te doen.
Met behulp van het suffix %, kunnen we de commandoregelparameter verwijderen -I ping.
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 gegevensbytes
64 bytes van fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 tijd=0.106 ms
64 bytes van fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 tijd=0.453 ms (DUP!)
64 bytes van fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 tijd=0.606 ms (DUP!)
64 bytes van fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 tijd=6.23 ms (DUP!)
64 bytes van fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 tijd=157 ms (DUP!)
64 bytes van fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 tijd=159 ms (DUP!)
64 bytes van fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 tijd=161 ms (DUP!)
64 bytes van fe80::23d:e8ff:feec:958c%enp3s2: icmp_seq=1 ttl=64 tijd=179 ms (DUP!)
--- ff02::1%enp3s2 pingstatistieken ---
1 pakketten verzonden, 1 ontvangen, +7 duplicaten, 0% pakketverlies, tijd 0ms
rtt min/avg/max/mdev = 0.106/82.858/179.216/81.281 ms
[mark@opy ~]$Antwoorden van Link-Local adressen
Van deze all-nodes multicast ping hebben we in totaal 6 unieke antwoorden gekregen.
Deze antwoorden kwamen van unicast Link-Local adressen van IPv6-knooppunten. Bijvoorbeeld, hier is het eerste antwoord:
64 bytes van fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 tijd=0.106 msUnicast Link-Local IPv6-adressen zijn vereist op alle interfaces die IPv6 ondersteunen [RFC4291], "Architectuur van IP-versie 6 adressering". Dit is omdat een IPv6-knooppunt altijd automatisch een unicast IPv6-adres heeft dat het kan gebruiken, in ieder geval om te communiceren met andere knooppunten via zijn rechtstreeks aangesloten verbindingen. Dit omvat communicatie met applicaties op andere hosts via de Link-Local adressen van hosts.
Dit vereenvoudigt de ontwikkeling en implementatie van protocollen zoals IPv6 Neighbor Discovery en OSPFv3. Het stelt ook eindgebruikertoepassingen op hosts in staat om gegevens uit te wisselen via de verbinding zonder dat enige andere ondersteunende infrastructuur voor IPv6 vereist is op de verbinding. Voor directe communicatie tussen aangesloten IPv6-hosts is geen IPv6-router of DHCPv6-server nodig in de verbinding.
Link-Local adressen beginnen met een 10-bits prefix fe80, gevolgd door 54 null-bits en dan een 64-bits interface identifier (IID). In het bovenstaande eerste antwoord, 2392:6213:a15b:66ff — is dit de 64-bits IID.
Geloopte Multicast
Standaard worden multicast-pakketten intern teruggestuurd naar het knooppunt dat ze verzendt. Dit gebeurt voor zowel IPv6- als IPv4-adressering.
De reden voor dit standaardgedrag is dat bij het verzenden van multicast-pakketten er ook een luisterend lokaal multicast-applicatie kan zijn dat op hetzelfde verzendende host draait, evenals ergens in het netwerk. Deze lokale applicatie moet ook de multicast-pakketten ontvangen.
We kunnen deze multicast-lokale cyclus zien in onze ping-uitvoer:
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 gegevens bytes
64 bytes van fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 tijd=0.106 ms
64 bytes van fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 tijd=0.453 ms (DUP!)
...Het eerste en snelste antwoord (0,106 ms in vergelijking met 0,453 ms) komt van het Link-Local adres dat op de interface enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Hulpprogramma ping biedt een manier om lokale feedback van multicast-verzending te onderdrukken met de parameter -L. Als we een ping all-nodes multicast met deze vlag verzenden, worden de antwoorden beperkt tot externe knooppunten. We ontvangen geen antwoord van het Link-Local adres van de verzendende interface.
[mark@opy ~]$ ping -L -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 gegevens bytes
64 bytes van fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 tijd=0.383 ms
64 bytes van fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 tijd=0.467 ms (DUP!)
...Ping Link-Local Adressen
Zoals je kunt raden, bieden unicast Link-Local adressen op zichzelf niet voldoende informatie om aan te geven welke interface gebruikt moet worden om ze te bereiken. Net als bij all-nodes multicast ping, moeten we ook de interface als commandoregelparameter opgeven. ping of de zone-ID met het adres bij het pingen van Link-Local adressen.
Deze keer kunnen we gebruiken -c, om het aantal verzonden en ontvangen pakketten te beperken ping, omdat we een unicast ping uitvoeren.
[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 van fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 tijd=0.395 ms
--- fe80::f31c:ccff:fe26:a6d9%enp3s2 pingstatistieken ---
1 pakketten verzonden, 1 ontvangen, 0% pakketverlies, tijd 0ms
rtt min/avg/max/mdev = 0.395/0.395/0.395/0.000 ms
[mark@opy ~]$Pingen (alle) andere IPv6-adressen?
In dit artikel hebben we gezien hoe we alle IPv6-knooppunten op het netwerk kunnen pingen, gebruikmakend van het all-nodes multicast IPv6-adres. ff02::1We hebben ook gezien hoe we aan kunnen geven welke interface gebruikt moet worden met het all-nodes multicast IPv6-adres, aangezien het adres op zichzelf deze informatie niet kan verstrekken. We hebben ofwel de commandoregelparameter gebruikt ping, of de interface via een suffix opgegeven. %.
Vervolgens hebben we geleerd over unicast Link-Local adressen, die adressen zijn die worden gebruikt voor antwoorden op all-nodes multicast echo-aanvragen ICMPv6.
We hebben ook gezien hoe multicast-pakketten terugkeren naar de verzendende knoop als standaard en hoe dit kan worden uitgeschakeld voor de tool. ping.
Tot slot hebben we een enkele Link-Local adres gepingd, waarbij we de suffix hebben gebruikt %, aangezien Link-Local adressen op zichzelf ook geen informatie geven over de uitgaande interface.
Wat als we alle andere knooppunten pingen en hun globale unicast adressen (GUA) (d.w.z. hun openbare adressen op het internet) of hun unieke lokale unicast adressen (ULA) krijgen? We zullen dit in het volgende blogartikel bespreken.
Dat is alles.
Meer informatie over onze cursus kun je vinden in.
Bron: habr.com
