Welche Adresse vergibt der Pool beim nächsten Verbindungsaufbau?
Pool-Adressen folgen einer Reihenfolge, die nicht zufällig ist: zuerst die gemerkte Adresse, dann die am längsten ungenutzte freie. Lies sie, bevor du eine Regel festnagelst.
Eine Regel, die gestern passte, passt heute nicht mehr, weil der Client über eine andere Tunneladresse zurückkam. Der Allocator ist jedoch nicht zufällig, und wer seine Reihenfolge kennt, macht aus dieser Überraschung ein vorhersehbares Ereignis. Er bevorzugt die Adresse, die derselbe Client zuvor hatte, greift sonst auf die am längsten ungenutzte freie zurück und vergisst alles, wenn man ihm keinen Ort zum Erinnern gibt. Regeln, die eine Lease voraussetzen, passen weiter, bis zu dem Tag, an dem sie es stillschweigend nicht mehr tun.
Die Reihenfolge, der der Allocator folgt
Bei einer Sitzung pro Common Name sucht der Allocator zuerst eine Adresse, die derselbe Client zuvor genutzt hat und die aktuell frei ist. Ist diese Adresse weg, nimmt er die freie Adresse, die am längsten ungenutzt war. Sind für denselben Namen parallele Sitzungen aktiviert, gilt die Bevorzugung der vorherigen Adresse nicht, und stattdessen wird die erste freie Adresse verwendet, weil die Sitzungen als getrennte Peers behandelt werden.
| Situation | Address chosen | Practical effect |
|---|---|---|
| Reconnect, old address still free | The remembered address | Rules appear stable for days |
| Old address taken by another client | Least recently used free address | A working rule silently stops matching |
| Concurrent sessions, same name | First free address, per session | One identity can hold several leases |
Zwei Folgen ergeben sich unmittelbar. Ein Client, der schnell wieder verbindet, behält meist seine Adresse, weshalb niemand den Mechanismus bemerkt, bis er sich ändert. Und ein anderes Gerät, das sich in diesem kurzen Fenster verbindet, kann die Adresse übernehmen, solange sie kurz frei ist; danach erhält der erste Client etwas anderes, und jede Regel, die auf die alte Nummer zeigt, ist falsch. Keines der beiden Ereignisse erzeugt eine Logzeile, die nach einem Fehler aussieht.
Warum eine Lease stabil wirkt und dann wandert
Stabilität ist hier eine emergente Eigenschaft davon, dass Wiederverbindungen eintreffen, bevor jemand anderes die Adresse beansprucht. Sie ist kein Versprechen und wird nicht durchgesetzt, solange der Client getrennt ist. Plane damit, dass sich die Adresse ändert, statt von ihr überrascht zu werden. Ein Pool, der kaum größer als die Gerätezahl ist, macht Kollisionen zum Normalfall, weil dem Rückgriff auf die am längsten ungenutzte Adresse fast nichts zur Auswahl bleibt.
Die Spitzenparallelität ist die Größe, an der man sich orientiert, nicht die Zahl der Nutzer. Wer von zwei Geräten gleichzeitig testet, oder ein Client, der sich vor Ablauf der alten Sitzung neu verbindet, belegt eine Zeit lang zwei Leases. Ein Pool, der nur für die Kopfzahl bemessen ist, erzeugt genau das Wechselspiel, das die Leute dem Server anlasten.
Die Persistenzdatei merkt sich, sie reserviert nicht
Eine Adresse, die einen Dienstneustart übersteht, braucht eine Persistenzdatei. Sie speichert beim Herunterfahren Clientnamen und Adresse und liest beides beim Dienststart wieder ein, weshalb ein geplanter Neustart nicht mehr alle geschriebenen Regeln durchmischt.
ifconfig-pool-persist /etc/openvpn/ipp.txt
server 10.8.0.0 255.255.255.0Was sie nicht tut, ist die Adresse festzuhalten, während der Client weg ist. In dieser Lücke darf der Allocator die Nummer an jemand anderen vergeben, und die Datei hält dann eine veraltete Präferenz fest, die die nächste Verbindung nicht erfüllen kann. Behandle sie als Hinweis, der das Neustartverhalten verbessert, nicht als statische Adressierung.
Prüfe den Pool gegen jedes geroutete Subnetz, während du in der Datei bist. Ein überlappender Bereich vergibt Adressen, zu denen der Server nicht routen kann, und das Symptom ist ein Client, der sich verbindet, eine Adresse erhält und nichts erreicht.
Eine Adresse richtig festnageln
Wenn eine Firewallregel oder ein DNS-Eintrag wirklich eine feste Adresse braucht, weise sie zu, statt auf sie zu hoffen. Ein Eintrag in der Client-Konfiguration kann Adresse und Maske direkt vorgeben, und dieser Eintrag ist auf den effektiven Clientnamen geschlüsselt.
# client-config-dir entry for "laptop-acme"
ifconfig-push 10.8.0.50 255.255.255.0Halte feste Adressen außerhalb des dynamischen Pools, damit der Allocator dieselbe Nummer nie an eine andere Sitzung vergibt. Prüfe dann die Tunnel-Topologie, denn sie ändert, wie viele Pool-Adressen jeder Client verbraucht: die ältere Punkt-zu-Punkt-Anordnung verbraucht pro Client einen kleinen Block, während eine Subnetz-Anordnung je eine Adresse nutzt. Ein Pool, der unter der einen Topologie großzügig wirkt, kann unter der anderen erschöpfend sein.
Bestätige das Ergebnis auf dem Client, statt der Buchführung des Servers zu vertrauen. Sobald die Sitzung zurück ist, sieh dir die Schnittstellenadresse und die gepushte Route an, weil ein Log auf dem Server die angeforderte Adresse melden kann, während die Schnittstelle selbst eine andere hält.
Die Remote-Adresse ist eine eigene Frage
Die Adresse in der Remote-Zeile des Clients muss erreichbar sein, bevor irgendein Tunnel existiert. Trägt man dort eine Pool-Adresse ein, etwa den eigenen Tunnel-Endpunkt des Servers, versucht der Client, den Endpunkt durch einen noch nicht aufgebauten Tunnel zu erreichen, und das Ergebnis ist eine Schleife oder ein stilles Timeout statt einer Abkürzung.
Verwende den öffentlichen Endpunkt, den der Betreiber bereitgestellt hat, und halte den Pool für das vor, wofür er gedacht ist: Adressen innerhalb des Tunnels. Pool-Bereich, feste Zuweisungen und Persistenzpfad an einer Stelle festzuhalten erspart der nächsten Person, jede Lease als willkürlich zu behandeln.