Zwei Besitzer, eine Adresse: doppelte IPs auf einer TAP-Bridge

Ein Windows-Client hält 10.8.0.2 und funktioniert, bis sich die Startreihenfolge ändert; dann wird dieselbe Adresse als Konflikt gemeldet, obwohl sich am Client nichts geändert hat. Ein zweiter Host im selben gebrückten Segment beansprucht denselben Wert, und die Maschine, die mit der Konfiguration zuletzt fertig wird, verliert meist. Beide glauben, sie besäßen ihn, und der Verlierer hört still auf, eine Adresse zu verwenden, die ihm zugewiesen wurde. Genau die Behandlung als Zeitproblem sorgt dafür, dass es bei jedem Neustart wiederkehrt.

Lesen Sie die Konfliktbelege, bevor Sie eine Bridge anfassen

Windows meldet einen Adresskonflikt zusammen mit der Hardwareadresse des anderen Anspruchstellers. Diese Hardwareadresse ist die nützliche Tatsache, denn sie zeigt auf genau eine Schnittstelle auf genau einem Host, während der angezeigte Ereignisname nichts darüber sagt, wo das Duplikat sitzt. Notieren Sie die Hardwareadresse, bevor Sie irgendetwas ändern.

Die ARP-basierte Duplikaterkennung prüft vor der Nutzung einer Adresse auf konkurrierende Besitzer und beobachtet danach weiter. Deshalb kann ein Host, der während der Netzkonfiguration abwesend war, noch eine Stunde später einen Konflikt auslösen. Die Prüfung ist keine einmalige Kontrolle beim Start. Eine Maschine, die danach auftaucht, kann eine Adresse übernehmen, die den ganzen Tag ruhig genutzt wurde, und deshalb liest sich der Fehler wie ein Rennen statt wie ein Konfigurationsfehler.

Ein Konfliktereignis allein sagt nicht, welche Konfiguration den anderen Anspruch erzeugt hat, und wer Adressen experimentell löscht, zerstört die Zuordnung, die es gesagt hätte. Der Sinn der Belege ist, aus einer Hardwareadresse eine Schnittstelle zu machen, die Sie prüfen können. Die Suche im Inventar nach Maschinennamen führt Sie meist zum falschen Host.

Erfassen Sie jeden Anspruch im Segment

Ein gebrücktes TAP-Setup verbindet Ethernet-Segmente, die früher getrennt waren, sodass Adressen, die in ihren eigenen Netzen eindeutig waren, kollidieren können, sobald Frames eine Strecke teilen. Deshalb gibt es diese Fehlerklasse in einem VPN und nicht in den gerouteten Netzen, die es ersetzt hat. Zählen Sie jeden möglichen Besitzer auf statt nur den ersten Verdacht.

Gehen Sie die Liste in dieser Reihenfolge durch: die Adressen auf jedem Bridge-Gerät und seinen Mitglieds-Ports, der OpenVPN-Pool und jede feste Zuweisung pro Client sowie jeder DHCP-Server, der das gebrückte Segment abdeckt. Gleichen Sie dann die Hardwareadresse aus dem Konfliktbericht mit den gefundenen Schnittstellen ab.

ip -4 addr show | grep -E 'inet |^[0-9]+: '
bridge link show
ip neigh show dev br0

Der Pool und der DHCP-Bereich sind die zwei Besitzer, die man vergisst. Drucken Sie beide Bereiche zusammen aus und suchen Sie nach einer Überschneidung, bevor Sie etwas anderes tun. Eine von Hand vergebene Bridge-Adresse und ein Pool, der denselben Wert ausgibt, kollidieren früher oder später, und die Kollision wirkt zufällig, bis beide Bereiche nebeneinander ausgedruckt sind.

Nummerieren Sie Bridges nur dort, wo sie eine Identität brauchen

In einer normalen Host-Bridge trägt das Bridge-Gerät die Konfiguration der dritten Schicht des Hosts, und die Ethernet- und TAP-Mitglieder wirken als Ports. Jedem Mitglied eine eigene Adresse zu geben oder ein Einrichtungsskript unverändert auf mehrere Maschinen zu kopieren, ist der Weg, auf dem ein einziges Segment drei Besitzer desselben Werts bekommt. Die Mitglieder brauchen keine eigenen Identitäten, um Frames weiterzuleiten. Sie brauchen genau eine Identität pro Host, der in diesem Segment erreichbar sein muss.

Eine Bridge, die nur Frames vermittelt, braucht in diesem Segment überhaupt keine Adresse. Lässt man sie unnummeriert, entfällt eine ganze Klasse von Kollisionen, vorausgesetzt, der Host hat noch einen von Ihnen geprüften Verwaltungsweg. Prüfen Sie zuerst den Zugang, entfernen Sie zweitens die Adresse und kontrollieren Sie drittens die Erreichbarkeit.

Ist die Adresse, die Sie löschen wollen, der einzige Weg in die Maschine, dann ist ihr Löschen als Experiment ein selbst verschuldeter Ausfall und keine Diagnose. Prüfen Sie den Out-of-Band-Weg, bevor Sie irgendetwas testen.

Sorgen Sie dafür, dass die Korrektur einen Neustart übersteht

Eine laufende Schnittstelle zu ändern, behebt den aktuellen Start und sonst nichts. Was auch immer die Adresse beim Start neu erzeugt, stellt den Konflikt beim nächsten Neustart wieder her, und Sie werden schließen, die Korrektur habe nicht funktioniert, obwohl sie in Wahrheit nie dauerhaft war. Notieren Sie, welche Datei Sie geändert haben, damit der nächste Neustart eine Entscheidung bestätigt statt eine Überraschung zu offenbaren.

Finden Sie den Besitzer dieser Konfiguration: ein Netzwerkmanager-Profil, eine Datei pro Schnittstelle, eine Container- oder VM-Definition oder ein cloud-init-Fragment. Ändern Sie sie dort und starten Sie dann bewusst einen betroffenen Host neu, um zu bestätigen, dass der neue Wert zurückkommt. Ein Neustart ist der einzige Test, der Dauerhaftigkeit beweist.

Reservieren Sie die Bridge-Adressen innerhalb des DHCP-Bereichs als Ausschlüsse oder verschieben Sie sie aus ihm heraus. Eine Reservierung, die nur in einer Tabelle existiert, ist kein Ausschluss, und der Zuteiler liest sie nicht.

Beweisen Sie es mit allen Clients online

Eine einzige erfolgreiche Verbindung beweist nichts, denn das ursprüngliche Symptom trat nur auf, wenn sich die Reihenfolge änderte. Bringen Sie jeden vorgesehenen Client hoch, variieren Sie die Startreihenfolge und wiederholen Sie es nach einem Neuverbinden. Starten Sie dann den Host neu, der das Rennen früher verlor, und bestätigen Sie, dass die Adresse überlebt.

Zur direkten Bestätigung prüfen Sie vor der Adressvergabe auf einen doppelten Besitzer und beobachten danach die Nachbartabelle. Antwortet nichts auf die Prüfung und bleibt die Adresse über einen vollen Neustartzyklus eindeutig gehalten, ist der Konflikt gelöst und nicht bloß verborgen. Die folgenden Befehle führen beide Kontrollen auf dem Bridge-Gerät aus. RFC 5227 beschreibt das Prüf- und Ankündigungsverhalten, das diese Werkzeuge ausüben, und ist die Referenz, die man zitiert, wenn jemand vorschlägt, die Erkennung stattdessen abzuschalten.

arping -D -I br0 10.8.0.2
ip neigh show dev br0 | grep 10.8.0.2

Eine Prüfung ohne Antwort ist das erwartete Ergebnis in einem sauberen Segment. Eine Prüfung, die eine Antwort hervorruft, liefert Ihnen die Hardwareadresse des verbleibenden Besitzers, also denselben Beleg, den das Windows-Ereignis Ihnen am Anfang gab. Bewahren Sie diese Ausgabe beim Änderungsnachweis auf, denn sie ist der einzige Beweis, dass die Adresse eindeutig gehalten wird.