Statische OpenVPN-Client-Adressen hinter OPNsense

Namen brauchen Adressen, die sich nicht bewegen, und die Pool-Datei von OpenVPN macht eine Adresse nur klebrig. Verliert man diese Datei oder stellt ein Zertifikat unter einem anderen Common Name neu aus, landet der zurückkehrende Client woanders im Pool, während sein DNS-Eintrag noch auf die alte Adresse zeigt. Die dauerhafte Antwort ist ein client-spezifischer Override, der die Adresse festnagelt, plus ein größeres Tunnelnetz, damit festgenagelte Adressen außerhalb des dynamischen Bereichs liegen. Die Arithmetik hinter dieser Erweiterung ist der Ort, an dem der meiste Wirrwarr wohnt.

OPNsense hält diese Overrides in den client-spezifischen Einstellungen des Servers, verschlüsselt über den Common Name des Zertifikats, was den Common Name zu einem Teil des Adressplans macht.

Ein klebriges Lease ist keine statische Adresse

Die Pool-Datei schreibt Address-to-Client-Zuordnungen und gibt sie zurück, wenn sich ein bekannter Client erneut verbindet. Das ist Bequemlichkeit statt eines Vertrags: Die Datei kann neu erzeugt werden, die Zuordnung verschwindet, wenn sich die Identität des Clients ändert, und zwei Server, die einen Pool teilen, werden sich nicht einig. Ein client-spezifischer Override funktioniert anders, weil die Adresse aus der Konfiguration statt aus der Historie kommt. Er übersteht auch einen Neustart und eine Neuinstallation der Appliance, sofern der Override mit der übrigen Konfiguration gesichert wird.

Die dynamische Alternative, das VPN mit einem Client-Connect-Skript und dynamischen Updates in DNS einzubinden, funktioniert und erfordert einen Resolver, der Updates annimmt, plus ein Skript bei jeder Verbindung. Auf einer Appliance ist man auf die Pakete des Herstellers beschränkt, und dort endet dieser Plan meistens.

Die /30-Arithmetik, die niemand mag

Unter der Standardtopologie net30 bekommt jeder Client sein eigenes /30: Die erste nutzbare Adresse geht an die Serverseite, die zweite an den Client. Overrides müssen daher außerhalb des dynamischen Tunnelnetzes des Servers liegen, was bedeutet, dass dieses Netz zuerst erweitert werden muss. Ein Server auf 10.8.0.0/24 kann auf 10.8.0.0/23 wechseln und die eine Hälfte des alten Bereichs für dynamische Clients und die andere Hälfte für Overrides lassen. Fügen Sie das ursprüngliche /24 als zusätzliches lokales IPv4-Netz hinzu, damit Verkehr in beide Hälften in den Tunnel geroutet wird.

Jede Override-Adresse muss auf einer /30-Grenze liegen, das letzte Oktett ist also ein Vielfaches von vier. Ein /30 auf 10.8.1.0 gibt dem Client 10.8.1.2, und das ist die Adresse, die der DNS-Eintrag trägt. Wählt man stattdessen 10.8.1.3, entsteht ein Client, der sich verbindet und keinen Verkehr durchlässt, weil die Adresse zu einem Subnetz gehört, das die Topologie ihm nie zugewiesen hat.

Der Plan lässt sich leichter halten, wenn Overrides von oben aus dem erweiterten Bereich nach unten vergeben werden, sodass der dynamische Pool in freien Raum hineinwächst statt um feste Inseln herum.

Lokale Netze und die Zone, die Clients abfragen

Client-zu-Client-Verkehr braucht eine eigene Erlaubnis. Die Liste der lokalen IPv4-Netze des Servers muss beide Hälften des Bereichs enthalten, dynamisch und statisch; ohne sie nimmt der Server ein Paket von einem Client an und hat keine Regel, die es zu einem anderen durchlässt. Das Symptom liest sich wie ein DNS-Fehler, weil der Name aufgelöst wird und die Verbindung trotzdem scheitert. Prüfen Sie gleichzeitig die Client-zu-Client-Einstellung, denn ein Eintrag für ein lokales Netz allein aktiviert keine Weiterleitung zwischen Peers.

Veröffentlichen Sie die Einträge in der Zone, die entfernte Clients tatsächlich abfragen. Ein Eintrag in einer Zone, die nur der LAN-Resolver bedient, ist für einen Client unsichtbar, dessen gepushter Resolver woanders hinzeigt, und weitere Einträge in der falschen Zone reparieren das nie. Bestätigen Sie die gepushte DNS-Option und die Suchdomäne bevor Sie etwas hinzufügen.

Was bei einer neuen Verbindung zu prüfen ist

Verbinden Sie den Client neu und bestätigen Sie, dass die zugewiesene Adresse zu seinem Override passt, bevor Sie irgendetwas anderes testen. Lösen Sie dann den Namen von einem zweiten Client auf und verbinden Sie sich über den Namen mit dem Dienst, was DNS-Eintrag, Route und Firewall zusammen prüft. Bestätigen Sie den Rückweg auf der Serverseite, denn ein Name, der aufgelöst wird, während der Dienst unerreichbar bleibt, ist ein Routing- oder Richtlinienproblem und kein Namensproblem. Halten Sie die Override-Tabelle neben der Zertifikatsliste, damit beides gemeinsam geprüft wird.

Ein Zertifikat, das unter einem anderen Common Name neu ausgestellt wird, passt nicht mehr zu seinem Override und schickt den Client zurück in den dynamischen Pool. Rechnen Sie nach jeder Identitätsänderung damit.