Statische OpenVPN-IP pro Client: ifconfig-push, nicht ipp.txt

Eine Zeile in ipp.txt zu bearbeiten fühlt sich wie das Reservieren einer Adresse an, ist es aber nicht. Diese Datei, benannt durch ifconfig-pool-persist, zeichnet auf, welche Adresse ein Common Name zuletzt hatte, damit der Pool dieselbe zurückgeben kann, wenn es passt. Nichts darin bindet die nächste Verbindung an diese Nummer.

Führen Sie die folgenden Prüfungen der Reihe nach aus. Jede bestätigt entweder den Mechanismus oder sagt Ihnen, dass Sie anhalten und eine Eingabe reparieren sollen.

Wozu die Persistenzdatei dient

Die Datei existiert, um Adressen über Neustarts hinweg stabil zu halten, was Wiederverbindungen freundlicher und Protokolle leichter lesbar macht. Sie wird als Historie gelesen und als Historie geschrieben, und der Zuteilungspfad bleibt frei, eine andere Adresse zu wählen, wenn der Hinweis nicht passt: ein anderer Pool, eine kollidierende Zuweisung oder ein Client, der ankam, nachdem der Pool voll war. Deshalb kann eine manuelle Änderung in der Datei perfekt aussehen und an der Verbindung nichts ändern. Behandeln Sie sie als Cache vergangener Entscheidungen und nicht als Quelle von Richtlinien.

Wenn Sie eine bestimmte Adresse für einen bestimmten Client brauchen, ist der dokumentierte Mechanismus ifconfig-push, und er gehört in die Konfiguration, die diesen Client besitzt.

Prüfen, dass der richtige Client ausgewählt ist

Eine explizite Zuweisung wird über den Common Name des Clients nachgeschlagen, sodass eine Datei, die auf die falsche Identität lautet, einfach nie gelesen wird. Bestätigen Sie, was der Server als Namen dieses Clients ansieht, besonders dort, wo username-as-common-name ihn nach der Authentifizierung ändert. Bestätigen Sie dann, dass der Dateiname genau diesem Wert entspricht, einschließlich Groß- und Kleinschreibung.

Denken Sie an Nebenläufigkeit, solange Sie hier sind. Wenn duplicate-cn erlaubt ist, können mehrere Geräte dieselbe Identität vorweisen, und eine feste Adresse kann nicht für alle eindeutig sein. Entscheiden Sie, ob die feste Adresse es wert ist, gleichzeitige Sitzungen für diese Identität abzulehnen, denn diese beiden Anforderungen lassen sich nicht zugleich erfüllen.

Prüfen, dass die Zahlen zur Topologie passen

Die Bedeutung der Argumente hängt von der Tunnel-Topologie ab, und hier richtet ein kopiertes Beispiel den größten Schaden an. In der älteren net30-Anordnung belegt jeder Client einen Block aus vier Adressen, sodass das Push ein Adresspaar liefert. In der Subnetz-Topologie erhält der Client eine Adresse plus die Maske des Pools, und die Paarform ist falsch. Lesen Sie die Topologie aus der laufenden Konfiguration, bevor Sie die Zeile schreiben.

# /etc/openvpn/ccd/partner-a   (subnet topology)
ifconfig-push 10.44.0.61 255.255.255.0

Prüfen Sie die Adresse gegen alles andere, was sie besitzen könnte: eine weitere explizite Zuweisung, den Bereich des dynamischen Pools und jede statische Route, die einen festen Host voraussetzt. Eine Adresse, die den Pool überlappt, funktioniert so lange, bis der Pool sie jemand anderem gibt, und dieser Fehler wird zufällig wirken.

Das Ergebnis auf einer neuen Verbindung prüfen

Eine bestehende Sitzung behält die Adresse, die sie erhalten hat, daher ist der einzige aussagekräftige Test eine neue Verbindung. Trennen Sie den Client, verbinden Sie ihn erneut und lesen Sie die Adresse, die er tatsächlich erhalten hat, zusammen mit den Routen, die mitkamen. Ist die Adresse weiterhin dynamisch, wurde die Zuweisung nicht angewandt, und der nächste Schritt ist der Blick in die Konfiguration statt einer weiteren Änderung an der Historien-Datei.

Halten Sie die Belege zusammen: den Clientnamen, die passende Datei, die zugewiesene Adresse und den Pool, aus dem sie kam.

Schließlich ist eine feste Tunneladresse kein Gerätenachweis. Sie kennzeichnet einen Platz im Adressplan, während die Authentifizierung weiterhin auf dem Zertifikat und dem Konto beruht. Die Verwechslung beider macht aus einem Adresskonflikt eine Sicherheitsannahme, die niemand aufgeschrieben hat.