OpenVPN-Server mit nopool: einen expliziten Poolbereich deklarieren

Server-Helfer konfigurieren ein Subnetz und füllen es dann mit einem dynamischen Pool eigener Wahl. Diese Vorgabe ist bequem, bis einige Adressen außerhalb der Zuteilung bleiben müssen — sei es, weil sie für feste Zuweisungen reserviert oder für ein künftiges Segment zurückgehalten werden. Den automatischen Pool zu unterdrücken und den Bereich selbst zu deklarieren kostet zwei Zeilen und eine bewusste Entscheidung darüber, welche Adressen nicht zur Zuteilung gehören. Der Rest ist Betriebsdisziplin: Bestandsaufnahme, Anwenden, Prüfen, Zurückrollen.

Das ist eine Änderung an einem laufenden Dienst, also behandeln Sie sie als Betriebsaufgabe: erst Bestandsaufnahme, dann Anwendung über den normalen Lebenszyklus, Prüfung mit einem neuen Client und ein bereitgehaltener Rückweg.

Beginnen Sie mit dem Subnetz, das Sie bereits haben

Lesen Sie die aktuelle Serverkonfiguration und die Adressen, die Clients tatsächlich halten. Die Pooländerung ergibt nur gegenüber dieser Ausgangslage Sinn, und die Ausgangslage ist nicht immer das, was die Datei nahelegt, weil ein verwaltetes Produkt oder ein Konfigurationsgenerator Eigentümer der Datei sein kann, die Sie lesen.

grep -nE '^(topology|server|ifconfig-pool|max-clients|client-config-dir)' /etc/openvpn/server/lab.conf
ip -4 addr show tun0

Bestätigen Sie die geltende Topologie. Bei der Subnetz-Topologie nimmt jeder Client eine Adresse aus dem Pool; ältere net30-Layouts teilen jedem Client einen kleinen Block zu, und die Arithmetik ist völlig anders. Läuft der Server noch auf net30, ist diese Seite die falsche Migrationsanleitung und die Poolnummern bedeuten nicht, was Sie erwarten. Prüfen Sie diese Zeile, bevor Sie Adressarithmetik von anderswo übernehmen.

Notieren Sie die eigene Adresse des Servers, jede feste Zuweisung im Verzeichnis der Clientkonfigurationen und jede Adresse, von der eine Route oder eine Zugriffsregel abhängt. Diese Adressen müssen außerhalb des dynamischen Bereichs bleiben. Sie zuerst aufzuschreiben macht den Bereich zu einer Entscheidung statt zu einer Vermutung. Es gibt auch dem Rückweg etwas Konkretes zum Wiederherstellen.

nopool hinzufügen und den Bereich deklarieren

Das Helfer-Schlüsselwort akzeptiert nopool, das die Subnetzkonfiguration beibehält und den automatischen dynamischen Pool unterdrückt, wie das OpenVPN-2.6-Handbuch beschreibt. Die explizite Zeile ifconfig-pool liefert dann den inklusiven Bereich, den Sie beabsichtigen, und ihre Netzmaske entspricht dem Subnetz. Beide Zeilen gehören in denselben Serverblock, weil ein Pool ohne sein Subnetz keine Bedeutung hat. Die Reihenfolge zwischen ihnen zählt nur für die Lesbarkeit, da der Helfer das Paar beim Start des Dienstes entfaltet.

topology subnet
server 10.70.0.0 255.255.255.0 nopool
ifconfig-pool 10.70.0.50 10.70.0.120 255.255.255.0

Beide Grenzen sind inklusive, das Beispiel bietet also einundsiebzig Adressen. Halten Sie die Serveradresse und jede feste Zuweisung außerhalb dieser Spanne; eine feste Zuweisung innerhalb des dynamischen Bereichs erzeugt eine Kollision, die von der Verbindungsreihenfolge abhängt, und das ist die schlimmste Art zum Debuggen. Lassen Sie einen Abstand zwischen dem reservierten Satz und dem Bereich, wenn die festen Zuweisungen wahrscheinlich wachsen.

Bereichsgröße und Parallelität sind getrennte Grenzen. Hundert Adressen bedeuten nicht hundert gleichzeitige Clients, wenn max-clients etwas anderes sagt, und ein Pool, der größer als die Parallelitätsgrenze ist, ist normal statt verschwenderisch. Entscheidend ist, dass beide Grenzen bewusst gewählt und nicht von einer Vorgabe geerbt werden.

Feste Zuweisungen aus dem dynamischen Bereich heraushalten

Ein client-spezifisches ifconfig-push ist ein anderer Mechanismus als die Poolzuteilung und muss Parameter verwenden, die zur aktiven Topologie passen. Im Subnetzmodus ist das eine einzelne Adresse und Netzmaske; ein net30-Paar zu übernehmen, weil es in einem alten Beispiel auftauchte, ist ein häufiger Fehler.

Die Zuteilungshistorie ist ein Hinweis, keine Autorität. Eine persist-Datei merkt sich, welcher Client welche Adresse hatte, sodass sich erneut verbindende Clients tendenziell dieselbe erhalten, und sie reserviert keine Adressen, gibt sie nicht frei und ersetzt keine feste Zuweisung. Muss ein bestimmtes Gerät immer eine bestimmte Adresse halten, verwenden Sie eine feste Zuweisung, statt sich auf die persist-Datei zu verlassen.

Prüfen Sie dann die Pfade, die von Adressen abhängen. Eine an Clients übermittelte Route, eine Firewallregel, die ein Subnetz zulässt, oder eine Überwachungsprüfung, die einen bestimmten Host erwartet, können alle den alten Bereich voraussetzen. Den Pool zu ändern, ohne sie zu lesen, verschiebt den Fehler an eine Stelle, die unzusammenhängend wirkt.

Über den Lebenszyklus anwenden, dann prüfen

Wenden Sie die Änderung so an, wie der Dienst normalerweise Konfiguration erhält — ob direkte Datei plus Neustart oder eine Verwaltungsschicht, die die Datei neu erzeugt. Eine manuelle Änderung an einer erzeugten Datei überlebt bis zur nächsten Erzeugung und nicht länger. Halten Sie fest, welcher Mechanismus die Datei besitzt, denn der nächste Betreiber muss wissen, wo dieselbe Änderung zu machen ist. Starten Sie dann einmal neu und lesen Sie das Protokoll, bevor Sie einen Client einladen.

systemctl restart openvpn-server@lab
journalctl -u openvpn-server@lab -n 30 --no-pager
# on a fresh client
ip -4 addr show tun0

Verbinden Sie einen Client, der zuvor nicht verbunden war, und bestätigen Sie, dass die Adresse innerhalb des deklarierten Bereichs und außerhalb des reservierten Satzes liegt. Bestätigen Sie dann den Rückweg: Der Client sollte erreichen, was die Richtlinie erlaubt, und nichts mehr. Eine Adresse, die zum Plan passt, aber keine funktionierende Route hat, ist keine erfolgreiche Änderung.

Verbinden Sie einen Client erneut, der eine Adresse aus dem alten Bereich hielt. Er sollte eine Adresse aus dem neuen Bereich erhalten, und jeder sitzungsbezogene Zustand, der an die alte Adresse gebunden war, sollte verschwunden sein. Behält er die alte Adresse, weist etwas anderes sie ihm zu, und der Pool ist nicht der Eigentümer, den Sie annehmen.

Eine Bereichsänderung zurückrollen

Bewahren Sie die vorherigen drei Zeilen in Ihrem Änderungsprotokoll auf, nicht nur die vorherige Datei. Sie wiederherzustellen und neu zu starten bringt die Zuteilung auf das alte Verhalten zurück, und Clients, die sich danach verbinden, erhalten Adressen daraus.

Zwei Warnungen gehören ins Protokoll. Clients, die beim Zurückrollen bereits verbunden sind, behalten ihre aktuellen Adressen, bis sie sich erneut verbinden, ein Rollback ist also nicht sofort in der gesamten Flotte wirksam. Und wenn der alte Bereich eine feste Zuweisung überlappte, stellt das Wiederherstellen auch die Kollision wieder her; genau diese Überlappung war der Grund für die Änderung, und sie braucht eine andere Lösung als ein Rollback.

Eine Pooländerung ist abgeschlossen, wenn ein neuer Client eine Adresse im Bereich erhält, eine reservierte Adresse nie ausgegeben wird und die Routen und Regeln, die diese Adressen nutzen, sich weiterhin wie beabsichtigt verhalten. Alles darunter lässt die nächste Person herausfinden, welches der drei nicht stimmt.