Es bleiben nur noch wenige Tage bis zum Start des neuen Kurses von OTUS. In diesem Zusammenhang möchten wir Ihnen eine nützliche Übersetzung zu diesem Thema vorstellen.
Eine Reihe von Blogartikeln, die Tipps und Empfehlungen zur Fehlersuche bei IPv6-Ping-Problemen (ICMPv6 Echo Request/Echo Reply) widmen.
Bitte beachten Sie, dass ich Linux (insbesondere Fedora 31) verwende, jedoch der Ping-Befehl für andere Betriebssysteme hoffentlich sehr ähnlich sein sollte.
Ping aller IPv6-Knoten im Netzwerk
Der erste und einfachste Tipp ist, alle IPv6-Knoten im Kanal zu pingen.
IPv6 verwendet Multicast-Adressen für alle Arten von „Eins-zu-viele“-Kommunikation. Es gibt keine Broadcast- (oder weitreichenden) IPv6-Adressen. Dies unterscheidet IPv6 von IPv4, wo es mehrere Typen von Broadcast-Adressen gibt, wie die „limited broadcast“ Adresse 255.255.255.255 [RFC1122].
Es gibt jedoch eine „All-Nodes-Multicast“-IPv6-Adresse, die wir verwenden werden, um alle IPv6-Knoten im Kanal zu pingen. Die „Broadcast“-Adresse ist tatsächlich einfach eine speziell benannte Multicast-Adresse, die eine Multicast-Gruppe umfasst, die alle Knoten einschließt. Beachten Sie, dass zum Beispiel das Bit „Gruppe“ oder die Multicast-Adresse in den Broadcast-Adressen von Ethernet auf der Datenverbindungsebene enthalten ist.
Die All-Nodes-Multicast-IPv6-Adresse für den Kanal lautet: ff02::1. ff bezeichnet die Multicast-IPv6-Adresse. Die nächste 0 ist ein Teil des Flags mit nicht gesetzten Bits.
Dann 2 bestimmt den Bereich der Multicast-Gruppe. Im Gegensatz zu Multicast-IPv4-Adressen haben Multicast-IPv6-Adressen einen Scope (Geltungsbereich). Der Wert des Scopes gibt an, in welchem Teil des Netzwerks Multicast-Pakete weitergeleitet werden dürfen. Sobald das Paket die Grenze des angegebenen Scopes erreicht, muss es verworfen werden, unabhängig davon, ob sein Hop-Count-Feld ungleich Null ist. Wenn der Hop-Count jedoch Null erreicht, bevor der angegebene Multicast-Gruppe-Bereich erreicht wird, wird es ebenfalls sofort verworfen. Hier ist die vollständige Liste der Multicast-Scopes für IPv6.
Schließlich ::1 zeigt die All-Nodes-Multicast-Gruppe an.
Über die Adresse ff02::1 sollte angemerkt werden, dass sie mehrdeutig ist. An einem IPv6-Knoten mit mehreren Schnittstellen, wie einem Router oder einem Multicast-Host, ist die Adresse ff02::1 Es gibt nichts, wo man angeben könnte, an welches Interface die ICMPv6-Echo-Anfragen gesendet werden sollen oder wo man erwarten kann, ICMPv6-Echo-Antworten zu erhalten, wenn sie eintreffen. ff02::1 gültig ist und auf jedem der Interfaces und Channels verwendet werden kann, die an einem Multi-Interface-Knoten angebracht sind.
Wenn wir also alle IPv6-Knoten im Kanal pingen, müssen wir auch der Utility mitteilen, ping welches Interface für IPv6 verwendet werden soll.
Die Schnittstellendefinition ist ein Kommandozeilenparameter
Wie wir bereits gesehen haben, ist die All-Nodes-Multicast-Adresse, die wir verwenden möchten — ff02::1 — gibt keine Informationen darüber, an welches Interface die ICMPv6-Echo-Anfragen und -Antworten gesendet und empfangen werden.
Wie können wir also das Interface angeben, das für den Bereich der Multicast-Adressen oder unicast Link-Local-Adressen verwendet werden soll?
Der erste und offensichtlichste Weg besteht darin, es als Parameter für die verwendete Anwendung anzugeben.
Für das Tool ping geben wir es über die Option -I.
[mark@opy ~]$ ping -w 1 -I enp3s2 ff02::1
ping: Warnung: Die Quelladresse könnte auf einem anderen Gerät als: enp3s2 ausgewählt werden
PING ff02::1(ff02::1) von :: enp3s2: 56 Datenbytes
64 Bytes von fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 Zeit=0.438 ms
64 Bytes von fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 Zeit=0.589 ms (DUP!)
64 Bytes von fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 Zeit=5.15 ms (DUP!)
64 Bytes von fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 Zeit=58.0 ms (DUP!)
64 Bytes von fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 Zeit=62.3 ms (DUP!)
64 Bytes von fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 Zeit=62.8 ms (DUP!)
--- ff02::1 Ping-Statistiken ---
1 Paket gesendet, 1 empfangen, +5 Duplikate, 0% Paketverlust, Zeit 0ms
rtt min/avg/max/mdev = 0.438/31.544/62.786/29.566 ms
[mark@opy ~]$Mit diesem All-Nodes-Multicast-Ping haben wir Antworten von 6 IPv6-Knoten erhalten. Die Antworten kamen von den Links-Local-IPv6-Adressen der Knoten, beginnend mit dem Präfix fe80::/10.
Um ping sendete nicht unendlich Echo-Anfragen von ICMPv6, bis wir es abbrachen, wir geben normalerweise die Anzahl der zu sendenden Pakete über die Option -c an. Dies erlaubt es ping jedoch nicht, mehr als eine ICMPv6-Echo-Antwort beim Senden von Multicast-ICMPv6-Echo-Anfragen zu akzeptieren und anzuzeigen. Stattdessen verwendeten wir die Option -w, um anzugeben, dass ping nach 1 Sekunde beendet werden soll, unabhängig davon, wie viele ICMPv6-Echo-Anfragen oder -Antworten gesendet oder empfangen wurden.
Ein weiterer Punkt, den man beachten sollte, ist (DUP!) Ausgabe bei der zweiten und nachfolgenden Antworten. Diese Pakete werden als Antwortduplikate identifiziert, da sie denselben ICMP-Sequenzwert aufweisen wie die einzelnen ICMPv6-Echo-Anfragen, die zuerst gesendet wurden. Sie erscheinen, weil das Multicast-ICMPv6-Echo zu mehreren individuellen Unicast-Antworten führt. Die Anzahl der Duplikate wird ebenfalls in der Statistikübersicht angegeben.
Schnittstellendefinition – Zonennummer
Eine weitere Möglichkeit, eine Schnittstelle zur Nutzung bereitzustellen, ist ein Teil des IPv6-Adresseparameters.
Wir können ein Beispiel dafür in der Ausgaben eines Pings beobachten, wo die Adressen der antwortenden IPv6-Knoten ebenfalls einen Suffix haben %enp3s2, zum Beispiel:
64 Bytes von fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 Zeit=0.438 msDiese Methode zur Festlegung von Schnittstellen ist formal in [RFC4007] beschrieben, "Architektur mit bestimmten IPv6-Adressen". Obwohl sie normalerweise als Schnittstelle des Betriebssystems bezeichnet werden, definieren sie in Wirklichkeit etwas Allgemeineres – "Zone" oder "Geltungsbereich".
Der Grund für die Existenz allgemeiner Zonen oder Geltungsbereich-Zonen liegt darin, dass ein IPv6-Knoten, wie in [RFC4007] erwähnt, mehrere verschiedene IPv6-Schnittstellen haben kann, die mit demselben Netzwerk verbunden sind. Diese Schnittstellen sind Mitglieder einer Zone.
Es sollte möglich sein, mehrere Schnittstellen innerhalb einer Zone unter einem Betriebssystem zu gruppieren; Ich weiß derzeit nicht, ob das unter Linux möglich ist und wie man das macht.
Mit dem Suffix %, können wir den Befehlszeilenparameter -I ping.
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 Datenbytes
64 Bytes von fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 Zeit=0.106 ms
64 Bytes von fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 Zeit=0.453 ms (DUP!)
64 Bytes von fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 Zeit=0.606 ms (DUP!)
64 Bytes von fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 Zeit=6.23 ms (DUP!)
64 Bytes von fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 Zeit=157 ms (DUP!)
64 Bytes von fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 Zeit=159 ms (DUP!)
64 Bytes von fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 Zeit=161 ms (DUP!)
64 Bytes von fe80::23d:e8ff:feec:958c%enp3s2: icmp_seq=1 ttl=64 Zeit=179 ms (DUP!)
--- ff02::1%enp3s2 Ping-Statistiken ---
1 Pakete gesendet, 1 empfangen, +7 Duplikate, 0% Paketverlust, Zeit 0ms
RTT min/avg/max/mdev = 0.106/82.858/179.216/81.281 ms
[mark@opy ~]$Antworten von Link-Local-Adressen
Von diesem All-Nodes-Multicast-Ping haben wir insgesamt 6 einzigartige Antworten erhalten.
Diese Antworten kamen von Unicast-Link-Local-Adressen der IPv6-Knoten. Zum Beispiel, hier ist die erste Antwort:
64 Bytes von fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 Zeit=0.106 msLink-Local IPv6-Adressen sind auf allen IPv6-fähigen Schnittstellen erforderlich [RFC4291], „Architektur der IP-Version 6-Adressen“. Der Grund dafür ist, dass ein IPv6-Knoten immer automatisch über eine unicast IPv6-Adresse verfügt, die er verwenden kann, um zumindest mit anderen Knoten über seine direkt angeschlossenen Schnittstellen zu kommunizieren. Dazu gehört die Kommunikation mit Anwendungen anderer Hosts über die Link-Local-Adressen der Hosts.
Dies vereinfacht die Entwicklung und Implementierung von Protokollen wie IPv6 Neighbor Discovery und OSPFv3. Es ermöglicht auch den Endbenutzeranwendungen auf Hosts, über die Verbindung Daten auszutauschen, ohne dass eine andere unterstützende IPv6-Infrastruktur auf dem Kanal erforderlich ist. Für die direkte Verbindung angeschlossener Hosts ist kein IPv6-Router oder DHCPv6-Server im Netzwerk erforderlich.
Link-Local-Adressen beginnen mit einem 10-Bit-Präfix fe80, gefolgt von 54 Nullbits und dann einer 64-Bit-Schnittstellen-ID (IID). In der oben genannten ersten Antwort 2392:6213:a15b:66ff — ist dies die 64-Bit-IID.
Looped Multicast
Standardmäßig werden Multicast-Pakete intern an den Knoten zurückgegeben, der sie sendet. Dies geschieht sowohl für IPv6 als auch für IPv4-Adressen.
Der Grund für dieses Standardverhalten ist, dass beim Senden von Multicast-Paketen möglicherweise auch eine hörende lokale Multicast-Anwendung auf dem sendenden Host aktiv ist, genauso wie irgendwo im Netzwerk. Diese lokale Anwendung muss ebenfalls die Multicast-Pakete empfangen.
Wir können diesen lokalen Multicast-Zyklus in unserer Ping-Ausgabe sehen:
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 Datenbytes
64 Bytes von fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 Zeit=0,106 ms
64 Bytes von fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 Zeit=0,453 ms (DUP!)
...Die erste und schnellste Antwort (0,106 ms im Vergleich zu 0,453 ms) stammt von der Link-Local-Adresse, die auf der Schnittstelle enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Das Tool ping bietet eine Möglichkeit, die lokale Rückkopplung der Multicastübertragung mit dem Parameter -Lzu unterdrücken. Wenn wir mit diesem Flag ein Ping an die All-Nodes-Multicast senden, werden die Antworten auf entfernte Knoten beschränkt. Wir erhalten keine Antwort von der Link-Local-Adresse der sendenden Schnittstelle.
[mark@opy ~]$ ping -L -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 Datenbytes
64 Bytes von fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 Zeit=0,383 ms
64 Bytes von fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 Zeit=0,467 ms (DUP!)
...Ping Link-Local-Adressen
Wie Sie sich denken können, bieten unicast Link-Local-Adressen für sich allein nicht genügend Informationen, um anzugeben, welches Interface für den Zugriff verwendet werden soll. Auch hier müssen wir das Interface als Kommandozeilenparameter angeben, ähnlich wie beim all-nodes multicast Ping. ping oder die Zone-ID zusammen mit der Adresse, wenn wir Link-Local-Adressen anpingen.
Dieses Mal können wir -c, um die Anzahl der gesendeten und empfangenen Pakete und Antworten zu begrenzen ping, da wir einen Unicast-Ping durchführen.
[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 Datenbytes
64 Bytes von fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 Zeit=0.395 ms
--- fe80::f31c:ccff:fe26:a6d9%enp3s2 Ping-Statistiken ---
1 gesendete Pakete, 1 empfangen, 0% Paketverlust, Zeit 0ms
rtt min/avg/max/mdev = 0.395/0.395/0.395/0.000 ms
[mark@opy ~]$Alle anderen IPv6-Adressen anpingen?
In diesem Artikel haben wir gesehen, wie man alle IPv6-Knoten im Netzwerk mit einer all-nodes multicast IPv6-Adresse anpingt. ff02::1Wir haben auch gelernt, wie man angibt, welches Interface mit der all-nodes multicast IPv6-Adresse verwendet werden soll, da die Adresse alleine diese Information nicht bereitstellen kann. Wir haben entweder den Kommandozeilenparameter ping, oder das Interface über den Suffix angegeben. %.
Dann haben wir etwas über unicast Link-Local-Adressen gelernt, die für Antworten auf all-nodes multicast ICMPv6-Echo-Anfragen verwendet werden.
Wir haben auch gesehen, wie Multicast-Pakete standardmäßig zum sendenden Knoten zurückkommen und wie man dies für das Dienstprogramm deaktiviert. ping.
Schließlich haben wir eine einzelne Link-Local-Adresse angepingt, indem wir den Suffix verwendeten, %, da Link-Local-Adressen für sich allein keine Informationen über das ausgehende Interface bereitstellen.
Wie wäre es mit dem Anpingen aller anderen Knoten und dem Abrufen ihrer globalen Unicast-Adressen (GUA) (also ihrer öffentlichen Adressen im Internet) oder ihrer Unique Local Addresses (ULA)? Dies werden wir im nächsten Blogartikel behandeln.
Das ist alles.
Erfahren Sie mehr über unseren Kurs in.
Quelle: habr.com
