OpenVPN-Adapter flattert unter Windows? Prüfen Sie auf eine doppelte IP

Unter Windows ist ein OpenVPN-Adapter, der eine Adresse übernimmt, sie wieder verwirft und das alle paar Sekunden wiederholt, meist kein DHCP-Fehler. Dem Adapter wird eine Adresse zugewiesen, auf die bereits etwas anderes antwortet, daher markiert Windows sie als unbrauchbar, und der Client beginnt von vorn. Das Client-Log bleibt still, weil der Konflikt darunter gelöst wird, im Netzwerk-Stack des Betriebssystems selbst.

Dieser Unterschied ist wichtig, denn jeder Fehlerbehebungsschritt, der auf die Tunnelkonfiguration zielt, wird eine doppelte Adresse auf der Serverseite übersehen.

Beginnen Sie mit dem Windows-Ereignisprotokoll, nicht mit dem Client-Log

Windows zeichnet Adresskonflikte im Systemprotokoll mit den Ereignis-IDs 4198 und 4199 auf. Das erste meldet einen erkannten Konflikt für eine Adresse, das zweite meldet, dass eine Schnittstelle die Adresse nicht nutzen konnte, mit der sie konfiguriert wurde. Keines erwähnt OpenVPN, und genau deshalb übersieht man sie leicht.

Holen Sie die letzten Ereignisse und vergleichen Sie ihre Zeitstempel mit dem Erneuerungszyklus des Adapters: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. Ein Konflikt alle fünfzehn Sekunden passt zu einem Client, der dieselbe Adresse gegen einen Inhaber erneut versucht, der weiterhin für sie antwortet. Ein einzelner Konflikt beim Verbindungsaufbau deutet stattdessen auf eine einmalige Kollision hin. So oder so lautet die nächste Frage, wer sonst die Adresse hält.

Drei Anordnungen bringen zwei Hosts auf eine Adresse

Fragen Sie den Server, wer die Adresse seiner Ansicht nach hält, und fragen Sie dann das Netzwerk, wer darauf antwortet. grep -H ifconfig-push /etc/openvpn/ccd/* listet jede feste Tunneladresse und das zugehörige Zertifikat auf. ip -4 neigh show dev tap0 zeigt, was die Bridge auf Schicht zwei gelernt hat. Der Vergleich dieser beiden Listen findet die meisten Duplikate in unter einer Minute.

Drei Anordnungen erklären fast alle: Ein Eintrag in client-config-dir legt eine Adresse für zwei Zertifikate fest, ein gebrücktes tap-Segment gibt einer Maschine eine Adresse, die ein anderer Host bereits statisch hat, oder eine veraltete Lease-Datei liefert eine Adresse zurück, die ein noch verbundener Client für seine hält. Der dritte Fall ist der heimtückischste, weil ifconfig-pool-persist Adressen für bekannte Clients bewusst wiederverwendet.

Machen Sie die Adresse eindeutig, statt um sie zu rennen

Die Boot-Reihenfolge entscheidet nur, wer heute gewinnt, daher ist jede Korrektur, die auf der Neustartreihenfolge beruht, vorübergehend. Geben Sie jedem Client seine eigene ifconfig-push-Zeile, oder vergeben Sie statische Adressen aus einem Bereich, den keine Bridge- oder Serverschnittstelle berührt. Prüfen Sie die Clientliste auch auf doppelte Common Names, denn duplicate-cn lässt zwei Sitzungen eine Identität und damit eine feste Adresse teilen. Wenn ein gebrücktes Gerät wirklich eine feste Adresse braucht, verschieben Sie es in sein eigenes Subnetz oder reservieren Sie sie aus dem Pool an einer Stelle, die der Server festhält.

Löschen Sie die Persist-Datei erst, wenn Sie wissen, welche Leases sie enthält, sonst vergibt die nächste Wiederverbindung wieder dieselben Adressen.

Starten Sie in der richtigen Reihenfolge neu und bestätigen Sie einen Inhaber pro Adresse

Wenden Sie die Änderung zuerst auf dem Server an und verbinden Sie dann die Clients neu, damit sich jeder Teilnehmer gegen den korrigierten Pool registriert. Werden die Clients zuerst neu gestartet, behalten sie Adressen, die der Server weiterhin für belegt hält. Lesen Sie nach dem Neustart die Statusdatei und bestätigen Sie, dass jeder Common Name einmal mit einer Adresse erscheint. Zwei Einträge für einen Namen bedeuten, dass eine alte Sitzung nie geschlossen wurde, nicht dass der Pool defekt ist.

Wenn ein Client seine Adresse immer noch nicht halten kann, prüfen Sie, ob eine Bridge-Schnittstelle auf demselben Host sie trägt. Eine Bridge, die eine Adresse von einem Herstellergerät geerbt hat, beantwortet ARP dafür, selbst wenn der VPN-Server diese Adresse bereits einem Client übergeben hat.

Beobachten Sie über einen vollen Erneuerungszyklus, bevor Sie das Ticket schließen

Eine saubere Messung beweist nichts. Beobachten Sie den Adapter mindestens zehn Minuten und erzwingen Sie dazwischen eine Wiederverbindung: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. Die Adresse sollte die Wiederverbindung überstehen und in einem bevorzugten Zustand bleiben.

Führen Sie dann die Ereignisabfrage aus dem ersten Schritt erneut aus und bestätigen Sie, dass sie nichts Neues liefert. Ein stilles Protokoll über eine Wiederverbindung hinweg ist der Beleg, dass der Konflikt weg ist, während ein stilles Protokoll nach einer einzigen Verbindung nur bedeutet, dass das Rennen noch nicht stattgefunden hat. Testen Sie schließlich die Ressource, für die der Tunnel existiert, denn eine Bridge, die ihre Adresse verloren hat, kann einen Herstellerpfad brechen, während das VPN selbst gesund aussieht.

Notieren Sie den Poolbereich, jede feste Adresse und den Host, der sie hält, in den Servernotizen. Die nächste Kollision ist dann in Minuten zu erkennen statt an einem Nachmittag neu zu entdecken.