Wéi eng Adress gëtt de Pool bei der nächster Verbindung aus?
Pooladressen follegen enger Rei, déi net zoufälleg ass: fir d'éischt déi gemierkt Adress, duerno déi am längsten onbenotzt fräi. Liest se, ier Dir eng Regel festleet.
Eng Regel, déi gëschter gepasst huet, passt haut net méi, well de Client iwwer eng aner Tunneladress zréckkoum. Den Allocator ass awer net zoufälleg, a wien seng Rei kennt, mécht aus där Iwwerraschung en erwaarbare Evenement. Hie bevirzugt d'Adress, déi dee selwechte Client virdru hat, gräift soss op déi am längsten onbenotzt fräi zréck a vergësst alles, wann Dir him net eppes gitt, wou hie sech erënnere kann. Regele, déi eng Lease virubsetzen, passe weider, bis zu deem Dag, wou se et stëlz net méi maachen.
D'Rei, déi den Allocator follegt
Mat enger Sitzung pro Common Name sicht den Allocator fir d'éischt eng Adress, déi dee selwechte Client virdru benotzt huet an déi aktuell fräi ass. Wann déi Adress fort ass, hëlt hien déi fräi Adress, déi am längsten onbenotzt war. Mat gläichzäitege Sitzunge fir dee selwechten Numm gëllt d'Prioritéit vun der vireger Adress net, an et gëtt amplaz déi éischt fräi Adress benotzt, well d'Sitzunge wéi getrennte Peers behandelt ginn.
| 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 |
Zwou Konsequenzen ergi sech direkt. E Client, deen séier erëm verbënnt, behält meeschtens seng Adress, an dofir mierkt keen de Mechanismus, bis hie sech ännert. An en anert Gerät, dat sech an deem klengen Zäitfenster verbënnt, kann d'Adress huelen, soulaang se kuerz fräi ass, duerno kritt den éischte Client eppes aneres an all Regel, déi op déi al Nummer ausgeriicht ass, ass falsch. Keent vun deenen zwou Evenementer erzeugt eng Logzeil, déi wéi e Feeler ausgesäit.
Firwat eng Lease stabil ausgesäit an duerno verréckelt
Stabilitéit ass hei eng emergant Eegenschaft vun Neiverbindungen, déi ukommen, ier een aneren d'Adress behaapt. Si ass kee Verspriechen, a si gëtt net duerchgesat, während de Client getrennt ass. Plane mat enger Adress, déi sech ännert, amplaz vun hir iwwerrascht ze ginn. E Pool, dee bal net méi grouss ass wéi d'Zuel vun den Apparater, mécht Kollisiounen normal, well dem Zréckgräifen op déi am längsten onbenotzt Adress bal näischt bleift fir auszewielen.
D'Spëtzeparallelitéit ass d'Gréisst, op déi Dir plangt, net d'Zuel vun de Benotzer. Een, dee vun zwou Apparate gläichzäiteg test, oder e Client, deen erëm verbënnt, ier déi al Sitzung ofleeft, besetzt eng Zäit zwou Leasen. E Pool, deen nëmmen op d'Kopfzuel berechent ass, produzéiert genee de Wiessel, deen d'Leit dem Server schold ginn.
D'Persistdatei erënnert sech, si reservéiert net
Eng Adress, déi e Service-Neistart iwwersteet, brauch eng Persistdatei. Si späichert beim Ofschalten de Clientnumm an d'Adress a liest se beim Start vum Service erëm, an dofir mischt en geplangten Neistart net méi all Regel duercher, déi Dir geschriwwen hutt.
ifconfig-pool-persist /etc/openvpn/ipp.txt
server 10.8.0.0 255.255.255.0Wat si net mécht, ass d'Adress halen, während de Client fort ass. An där Lück däerf den Allocator d'Nummer un een aneren iwwerginn, an d'Datei hält dann eng veroudert Präferenz fest, déi déi nächst Verbindung net erfëlle kann. Behandelt si als Hiweis, deen d'Neistartverhalen verbessert, net als statesch Adresséierung.
Iwwerpréift de Pool géint all geroutete Subnetz, während Dir an der Datei sidd. En iwwerlappenden Beräich verdeelt Adressen, op déi de Server net ka routeren, an d'Symptom ass e Client, deen sech verbënnt, eng Adress kritt an näischt erreecht.
Eng Adress richteg festpinnen
Wann eng Firewallregel oder en DNS-Andrag wierklech eng fest Adress brauch, weist se zou, amplaz ze hoffen. En Eintrag an der Client-Konfiguratioun ka vun direkter Adress a Mask schécken, an deen Eintrag ass op den effektive Clientnumm geschlësselt.
# client-config-dir entry for "laptop-acme"
ifconfig-push 10.8.0.50 255.255.255.0Halt fest Adressen ausserhalb vum dynamesche Pool, sou datt den Allocator déiselwecht Nummer ni un eng aner Sitzung gëtt. Préift dann d'Tunneltopologie, well si ännert, wéivill Pooladressen all Client verbraucht: déi méi al Punkt-zu-Punkt-Anordnung verbraucht pro Client e klengt Block, während eng Subnetz-Anordnung jee eng Adress benotzt. E Pool, dee sech ënner der enger Topologie grousszügeg ausgesäit, ka sech ënner der anerer erschëpfen.
Bestätegt d'Resultat um Client, amplaz der Buchhaltung vum Server ze vertrauen. Soubal d'Sitzung zréck ass, kuckt d'Interfaceadress an déi gepushte Route un, well en Log um Server d'Adress melle kann, déi ugefrot gouf, während d'Interface selwer eng aner hält.
D'Remote-Adress ass eng eegen Fro
D'Adress an der Remote-Zeil vum Client muss erreechbar sinn, ier en Tunnel existéiert. Setzt Dir do eng Pooladress an, wéi den eegenen Tunnelenpunkt vum Server, versicht de Client, den Ennpunkt duerch en Tunnel z'erreechen, deen nach net gebaut ass, an d'Resultat ass eng Schleif oder en stille Timeout amplaz enger Ofkierzung.
Benotzt den ëffentlechen Ennpunkt, deen den Bedreiwer geliwwert huet, a haalt de Pool fir dat, wofir hien entworf ass: Adressen am Tunnel. De Poolberäich, déi fest Zousetzungen an de Persistpad op enger Plaz festzehalen erspuert der nächster Persoun, all Lease als wëllkürlech ze behandelen.