Ce adresă va aloca pool-ul la următoarea reconectare?
Adresele din pool urmează o ordine care nu este aleasă la întâmplare: mai întâi adresa memorată, apoi cea liberă nefolosită cel mai mult timp. Citește-o înainte de a fixa o regulă.
O regulă care se potrivea ieri nu se mai potrivește astăzi, pentru că clientul a revenit cu altă adresă de tunel. Alocatorul nu este însă aleatoriu, iar cine îi cunoaște ordinea transformă acea surpriză într-un eveniment previzibil. Preferă adresa pe care același client a avut-o înainte, recurge la adresa liberă nefolosită cel mai mult timp și uită totul dacă nu îi dai unde să țină minte. Regulile care presupun o concesiune continuă să se potrivească până în ziua când, în tăcere, nu mai fac asta.
Ordinea pe care o urmează alocatorul
Cu o singură sesiune per common name, alocatorul caută mai întâi o adresă pe care același client a folosit-o anterior și care este liberă acum. Dacă acea adresă a dispărut, ia adresa liberă rămasă nefolosită cel mai mult timp. Cu sesiuni simultane activate pentru același nume, preferința pentru adresa anterioară nu se aplică și se folosește în schimb prima adresă liberă, pentru că sesiunile sunt tratate ca peer-i separați.
| 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 |
Din asta decurg imediat două consecințe. Un client care se reconectează repede își păstrează de obicei adresa, motiv pentru care nimeni nu observă mecanismul până când nu se schimbă. Iar un alt dispozitiv care se conectează în acea fereastră mică poate lua adresa cât timp este scurt timp liberă, după care primul client primește altceva și orice regulă legată de numărul vechi este greșită. Niciunul dintre cele două evenimente nu produce o linie de jurnal care să pară o defecțiune.
De ce o concesiune pare stabilă și apoi se mută
Stabilitatea aici este o proprietate emergentă a reconectărilor care sosesc înainte ca altcineva să revendice adresa. Nu este o promisiune și nu este impusă cât timp clientul este deconectat. Planifică pentru schimbarea adresei în loc să fii surprins de ea. Un pool abia mai mare decât numărul de dispozitive face coliziunile obișnuite, pentru că replierea pe adresa nefolosită cel mai mult timp aproape nu are dintre ce alege.
Concurrența de vârf este cifra după care se dimensionează, nu numărul de utilizatori. Cineva care testează de pe două dispozitive simultan, sau un client care se reconectează înainte ca vechea sesiune să expire, ocupă două concesiuni o vreme. Un pool dimensionat doar pentru numărul de persoane va produce exact rotația pe care oamenii o pun pe seama serverului.
Fișierul de persistență își amintește, nu rezervă
O adresă care supraviețuiește unei reporniri a serviciului are nevoie de un fișier de persistență. Acesta salvează numele clientului și adresa la oprire și le recitește la pornirea serviciului, motiv pentru care o repornire planificată nu mai amestecă toate regulile scrise.
ifconfig-pool-persist /etc/openvpn/ipp.txt
server 10.8.0.0 255.255.255.0Ce nu face este să țină adresa în timp ce clientul lipsește. În acel interval alocatorul este liber să dea numărul altcuiva, iar fișierul consemnează atunci o preferință învechită pe care următoarea conexiune nu o poate respecta. Tratează-l ca pe un indiciu care îmbunătățește comportamentul la repornire, nu ca pe o adresare statică.
Verifică pool-ul împotriva fiecărei subrețele rutate cât timp ești în fișier. Un interval care se suprapune distribuie adrese către care serverul nu poate ruta, iar simptomul este un client care se conectează, primește o adresă și nu ajunge nicăieri.
Fixarea corectă a unei adrese
Când o regulă de firewall sau o înregistrare DNS are într-adevăr nevoie de o adresă fixă, atribuie-o în loc să speri la ea. O intrare de configurare per client poate împinge direct o adresă și o mască, iar acea intrare este indexată după numele efectiv al clientului.
# client-config-dir entry for "laptop-acme"
ifconfig-push 10.8.0.50 255.255.255.0Ține adresele fixe în afara pool-ului dinamic, astfel încât alocatorul să nu dea niciodată același număr altei sesiuni. Apoi verifică topologia tunelului, pentru că schimbă câte adrese din pool consumă fiecare client: vechea dispunere punct la punct consumă un bloc mic per client, în timp ce o dispunere în subrețea folosește câte o adresă fiecare. Un pool care pare generos într-o topologie poate fi epuizant în cealaltă.
Confirmă rezultatul pe client în loc să te bazezi pe evidența serverului. După ce sesiunea revine, uită-te la adresa interfeței și la ruta împinsă, pentru că un jurnal de pe server poate raporta adresa solicitată în timp ce interfața are alta.
Adresa remote este o întrebare separată
Adresa din linia remote a clientului trebuie să fie accesibilă înainte să existe vreun tunel. Dacă pui acolo o adresă din pool, cum ar fi propriul punct final al tunelului serverului, clientul încearcă să atingă punctul final printr-un tunel pe care nu l-a construit încă, iar rezultatul este o buclă sau un timeout tăcut în loc de o scurtătură.
Folosește punctul final public furnizat de operator și păstrează pool-ul pentru ceea ce a fost gândit: adrese din interiorul tunelului. Notarea intervalului pool-ului, a atribuirilor fixe și a căii de persistență într-un singur loc scutește următoarea persoană să trateze fiecare concesiune ca arbitrară.