Er blijven nog een paar dagen over tot het begin van een nieuwe stroom tegen het tarief van OTUS. In dit verband willen we graag een vertaling van nuttig materiaal over dit onderwerp met u delen.
Een reeks blogposts met tips en trucs voor het oplossen van IPv6-pingproblemen (ICMPv6 Echo Request/Echo Reply)
Houd er rekening mee dat ik Linux gebruik (in het bijzonder Fedora 31), maar de syntaxis van de ping-opdrachten voor andere besturingssystemen zou hopelijk erg op elkaar moeten lijken.
Ping alle IPv6-knooppunten op een kanaal
De eerste en eenvoudigste tip is om alle IPv6-nodes op de link te pingen.
IPv6 maakt gebruik van multicast-adressen voor alle soorten één-op-veel-communicatie. Er zijn geen broadcast (of broadcast) IPv6-adressen. Dit onderscheidt IPv6 van IPv4, waar er verschillende soorten broadcast-adressen zijn, bijvoorbeeld het “limited broadcast”-adres 255.255.255.255 [RFC1122].
Er is echter een “all-nodes multicast” IPv6-adres, dus we zullen dat gebruiken om alle IPv6-nodes op de link te pingen. (Een "broadcast"-adres is eigenlijk gewoon een speciaal genoemd multicast-adres, wat een multicast-groep is die alle knooppunten omvat. Merk op dat bijvoorbeeld de "groep"- of multicast-adresbit is ingeschakeld in Ethernet-broadcast-adressen op de linklaag ).
Multicast IPv6-adres voor alle knooppunten voor het kanaal: ff02::1. ff geeft een multicast IPv6-adres aan. De volgende 0 is het deel van de vlag met niet-ingestelde bits.
Volgende 2 definieert het gebied van een multicastgroep. In tegenstelling tot multicast IPv4-adressen hebben multicast IPv6-adressen een bereik. De scopewaarde geeft het deel van het netwerk aan waarover een multicastpakket mag worden doorgestuurd. Zodra een pakket de grens van het gespecificeerde bereik bereikt, moet het pakket worden verwijderd, ongeacht of het Hop Count-veld niet nul is. Als de hoptelling nul bereikt voordat de gespecificeerde multicastgroepgrens wordt bereikt, wordt deze natuurlijk ook onmiddellijk gereset. Hier is een volledige lijst met IPv6-multicast-scopes.
Tenslotte de ::1 specificeert een multicastgroep met alle knooppunten.
Over het adres ff02::1 Opgemerkt moet worden dat het dubbelzinnig is. Op een IPv6-host met meerdere interfaces, zoals een router of multihomed-host, wordt het adres ff02::1 er is niets waar u kunt opgeven naar welke interface ICMPv6-echoverzoeken moeten worden verzonden of naar welke interface u ICMPv6-echo-antwoorden kunt verwachten wanneer deze binnenkomen. ff02::1 is geldig en kan worden gebruikt op elk van de interfaces en kanalen die zijn aangesloten op het multi-interfaceknooppunt.
Dus als we alle IPv6-knooppunten op een link pingen, moeten we dit op de een of andere manier ook aan het hulpprogramma vertellen ping voor IPv6, welke interface u moet gebruiken.
Interfaces definiëren - Opdrachtregeloptie
Zoals we al hebben gezien, is het multicast-adres voor alle knooppunten dat we willen gebruiken − ff02::1 - biedt geen informatie over welke interface ICMPv6-echoverzoeken en echo-antwoordpakketten moeten verzenden en ontvangen.
Dus, hoe specificeren we de interface die moet worden gebruikt voor de multicast-adresruimte of unicast Link-Local-adresruimte?
De eerste en meest voor de hand liggende manier is om het als parameter aan te bieden aan de applicatie die we gebruiken.
Voor nut ping wij bieden het via de optie -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 ~]$Met behulp van deze multicast-ping op alle knooppunten ontvingen we reacties van 6 IPv6-knooppunten. De reacties kwamen van Link-Local IPv6-knooppuntadressen, te beginnen met het voorvoegsel fe80::/10.
Dat ping niet voor onbepaalde tijd ICMPv6-echoverzoeken blijft verzenden totdat we deze onderbreken, specificeren we meestal het aantal pakketten dat moet worden verzonden via de optie -c. Dit voorkomt echter ook dat ping meer dan één ICMPv6-echoantwoord accepteert en weergeeft bij het verzenden van een multicast ICMPv6-echoverzoek. In plaats daarvan hebben we de optie -w gebruikt om aan te geven dat de ping na 1 seconde moet worden voltooid, ongeacht hoeveel ICMPv6-echoverzoeken of echo-antwoorden er zijn verzonden of ontvangen.
Een ander ding om op te letten is (DUP!) uitvoer op de tweede en volgende antwoorden. Deze pakketten worden geïdentificeerd als dubbele antwoorden omdat ze dezelfde ICMP-reekswaarde hebben als de individuele ICMPv6-echoverzoeken die in de eerste plaats zijn verzonden. Ze verschijnen omdat een ICMPv6-multicast-echoverzoek resulteert in meerdere individuele unicast-reacties. Het aantal duplicaten wordt ook aangegeven in het statistiekenoverzicht.
Interfaces definiëren - Zone-ID
Een andere manier om een interface beschikbaar te maken voor gebruik is als onderdeel van een IPv6-adresparameter.
Een voorbeeld hiervan kunnen we zien in de ping-uitvoer, waar de adressen van de reagerende IPv6-hosts ook het achtervoegsel hebben %enp3s2, bijvoorbeeld:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msDeze methode voor het specificeren van interfaces wordt formeel beschreven in [RFC4007], "IPv6 Defined Address Architecture." Hoewel ze gewoonlijk de interface van het besturingssysteem worden genoemd, definiëren ze in feite iets algemeners: een ‘zone’ of ‘scope’.
De reden voor het hebben van meer algemene zones of scopezones is dat, zoals vermeld in [RFC4007], een IPv6-knooppunt verschillende IPv6-interfaces kan hebben die op hetzelfde kanaal zijn aangesloten. Deze interfaces zijn lid van dezelfde zone.
Het moet mogelijk zijn om meerdere interfaces binnen een zone onder het besturingssysteem te groeperen; Momenteel weet ik niet of dit mogelijk is onder Linux en hoe ik dit moet doen.
Het achtervoegsel gebruiken %<zone_id>, kunnen we de opdrachtregeloptie verwijderen -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-Local Adresreacties
Van deze multicast-ping op alle knooppunten hebben we in totaal 6 unieke reacties ontvangen.
Deze antwoorden kwamen van unicast Link-Local IPv6-hostadressen. Hier is bijvoorbeeld het eerste antwoord:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msUnicast Link-Local IPv6-adressen zijn vereist op alle IPv6-compatibele interfaces [RFC4291], “IP Version 6 Addressing Architecture”. De reden hiervoor is dat een IPv6-knooppunt altijd automatisch een unicast IPv6-adres heeft, dat het in ieder geval kan gebruiken om te communiceren met andere knooppunten op zijn direct verbonden links. Dit omvat ook de communicatie met applicaties op andere hosts via Link-Local hostadressen.
Dit vereenvoudigt het ontwerp en de implementatie van protocollen zoals IPv6 Neighbor Discovery en OSPFv3. Het maakt het ook mogelijk dat eindgebruikersapplicaties op hosts via het kanaal kunnen communiceren zonder dat er een andere ondersteunende IPv6-infrastructuur op het kanaal nodig is. Voor directe communicatie tussen aangesloten IPv6-hosts is geen IPv6-router of DHCPv6-server op de verbinding vereist.
Link-Local-adressen beginnen met een voorvoegsel van 10 bits fe80, gevolgd door 54 nulbits en vervolgens een 64-bits interface-identificator (IID). In het bovenstaande eerste antwoord 2392:6213:a15b:66ff is een 64-bits IID.
Geluste multicast
Standaard worden multicast-pakketten intern geretourneerd naar het knooppunt dat ze heeft verzonden. Dit gebeurt voor zowel IPv6- als IPv4-adressering.
De reden voor dit standaardgedrag is dat wanneer multicastpakketten worden verzonden, er mogelijk ook een luisterende lokale multicasttoepassing actief is op de verzendende host zelf, maar ook ergens op het netwerk. Deze lokale applicatie moet ook multicast-pakketten ontvangen.
We kunnen deze multicast-lokale lus zien in onze ping-uitvoer:
[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!)
...De eerste en snelste reactie (0,106 ms vergeleken met 0,453 ms) komt van het Link-Local-adres dat op de interface zelf is geconfigureerd enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Nut ping biedt een manier om lokale multicast-feedback te onderdrukken met behulp van de parameter -L. Als we met deze vlag een multicast-ping voor alle knooppunten verzenden, zijn de reacties 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 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 adressen
Zoals je misschien wel kunt raden, bieden unicast Link-Local-adressen op zichzelf ook niet genoeg informatie om aan te geven welke interface je moet gebruiken om ze te bereiken. Net als bij multicast-ping op alle knooppunten moeten we ook de interface opgeven als opdrachtregelparameter ping of zone-ID met adres bij het pingen van Link-Local-adressen.
Deze keer kunnen we gebruiken -com het aantal verzonden en ontvangen pakketten en antwoorden te beperken ping, omdat we 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 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) andere IPv6-adressen?
In dit artikel hebben we gezien hoe u alle IPv6-knooppunten op een kanaal kunt pingen met behulp van een multicast IPv6-adres voor alle knooppunten ff02::1. We hebben ook gezien hoe je kunt specificeren welke interface je moet gebruiken met een multicast IPv6-adres met alle knooppunten, omdat het adres zelf deze informatie niet kan leveren. We gebruikten de opdrachtregeloptie ping, of specificeer de interface met behulp van het achtervoegsel %<zone_id>.
Vervolgens leerden we over unicast Link-Local-adressen, dit zijn adressen die worden gebruikt om te reageren op multicast ICMPv6-echoverzoeken van alle knooppunten.
We hebben ook gezien hoe multicast-pakketten standaard worden teruggestuurd naar het verzendende knooppunt en hoe dit voor het hulpprogramma kan worden uitgeschakeld ping.
Ten slotte hebben we een enkel Link-Local-adres gepingd met behulp van het achtervoegsel %<zone_id>, aangezien Link-Local-adressen zelf ook geen informatie geven over de uitgaande interface.
Dus hoe zit het met het pingen van alle andere knooppunten en het verkrijgen van hun globale unicast-adressen (GUA's) (dat wil zeggen hun openbare adressen op internet) of hun unieke lokale unicast-adressen (ULA's)? We zullen dit in de volgende blogpost bekijken.
Dat is alles.
Meer informatie over onze cursus vindt u op.
Bron: www.habr.com