Stabile OpenVPN-Adressen sollten der Identität folgen, nicht der Quell-IP
Eine statische Adresse ist eine Aussage über eine Identität, nicht über eine Quell-IP. Wählen Sie den Schlüssel, halten Sie Reservierungen aus dem Pool heraus und legen Sie dann den Eigentümer der Zuweisung fest.
Adresspläne, die sagen „dieser Laptop bekommt 10.90.0.10“, sind in Wahrheit Aussagen über Identität: welches authentifizierte Gerät diese Adresse halten darf. Die aktuelle öffentliche IP dieses Geräts hat damit fast nichts zu tun, denn NAT und Roaming ändern sie, ohne zu ändern, wer der Benutzer ist. Baut man den Plan auf der Quelladresse auf, entstehen Regeln, die im ersten Hotelnetz brechen. Baut man ihn auf der authentifizierten Identität auf, entsteht ein Plan, der Reisen übersteht.
Beginnen Sie bei dem, was der Server prüfen kann, und entscheiden Sie dann, wofür die Adresse da ist.
Wählen Sie den Identitätsschlüssel vor der Adresse
Ein separates Client-Zertifikat pro Gerät gibt dem Server einen stabilen, prüfbaren Schlüssel für jedes Mitglied, was die sauberste Grundlage für eine statische Zuweisung ist. Ein Deployment mit Authentifizierung pro Benutzer kann stattdessen den Benutzernamen verwenden, solange die Konfigurationsauswahl demselben Feld folgt. Mischt man beide Modelle, entstehen Zuweisungen, die für einen Client zu einem Zertifikat und für einen anderen zu einem Benutzernamen passen, und niemand kann vorhersagen, welches gewinnt. Entscheiden Sie, welchen Schlüssel der Plan verwendet, bevor Sie eine einzige Reservierung schreiben.
Mit duplicate-cn können mehrere gleichzeitige Sitzungen denselben Common Name präsentieren, sodass eine feste Adresse sie nicht einzeln identifizieren kann. Das ist eine Eigenschaft des Identitätsmodells und nichts, was ein besserer Adressplan beheben kann.
Reservieren Sie Adressen außerhalb des dynamischen Bereichs
In einem Netz mit Subnetz-Topologie wie 10.90.0.0/24 halten Sie die niedrigen Adressen für benannte Mitglieder frei und legen den dynamischen Pool in einen getrennten Bereich. Eine Zuweisung für ein festes Mitglied sieht so aus ifconfig-push 10.90.0.10 255.255.255.0 in der Datei, die der Server für diese Identität auswählt. Das zweite Argument bedeutet unter net30 etwas anderes, daher ist das Beispiel nicht topologieneutral. Lesen Sie die Topologie, bevor Sie es kopieren.
Die Pool-Persistenz zeichnet aktuelle Leases auf und neigt dazu, dieselbe Adresse zurückzugeben, was eine Bequemlichkeit und keine Reservierung ist. Lassen Sie die Persistenzdatei nicht zur Eigentumsaufzeichnung werden, denn sie ändert sich mit der Verbindungshistorie und nicht mit der Richtlinie.
Die Zuweisungsrangfolge entscheidet, wer gewinnt
Das Handbuch dokumentiert eine Reihenfolge: Eine explizite Zuweisung, die während client-connect erzeugt wird, kann vor einem client-config-dir-Eintrag wirksam werden, der wiederum der gewöhnlichen Pool-Zuweisung vorausgeht. Diese Reihenfolge erklärt die meisten Meldungen „die feste Adresse wurde nicht angewendet“. Sie bedeutet auch, dass ein dynamischer Allocator, der sitzungsbezogene Konfiguration schreibt, eine statische Datei still überschreiben kann, die Sie für maßgeblich hielten.
Wählen Sie eine Schicht, die Zuweisungen besitzt, und machen Sie die anderen schreibgeschützt. Zwei Schichten, die beide beanspruchen zu entscheiden, erzeugen Zuweisungen, die vom Zeitpunkt abhängen.
Ein dynamischer Allocator braucht dasselbe Modell
Eine client-connect-Integration, die Adressen pro Sitzung ausgibt, ist ein kleiner Allocator mit den üblichen Allocator-Problemen. Er muss die anfragende Identität validieren, eine Adresse atomar reservieren, nur die unterstützte Ausgabe pro Verbindung ausgeben und die Reservierung bei Trennung oder Fehler freigeben. Gleichzeitige Anfragen brauchen eine Sperre oder eine Datenbankbedingung, keine Lese-dann-schreibe-Folge. Ohne Aufräumen verliert der Pool Adressen bis zum Neustart.
Halten Sie den Zustand des Allocators dort, wo der nächste Betreiber ihn lesen kann, und protokollieren Sie die Entscheidung Identität-zu-Adresse statt nur die Adresse.
Entscheiden Sie, ob die Adresse Richtlinie oder Bequemlichkeit ist
Wenn eine Firewall-Regel oder eine Route Verkehr von einer Tunneladresse erlaubt, dann nimmt die Adresse an der Zugriffsrichtlinie teil, und eine Neuzuweisung erbt diese Erlaubnis. Koordinieren Sie den Lebenszyklus von Identität, Adresse und Firewall, oder binden Sie die Regel an etwas, das nicht neu zugewiesen werden kann. Stabile Adressierung macht die Konfiguration lesbar; sie ersetzt keine Authentifizierung.
Schreiben Sie den Plan als Inventar mit einem Eigentümer pro Eintrag und prüfen Sie ihn, wenn ein Gerät außer Betrieb genommen wird. Die ungenutzte Reservierung ist die, die versehentlich wiederverwendet wird.