IP static OpenVPN per client: ifconfig-push, nu ipp.txt

Editarea unei linii în ipp.txt pare a rezerva o adresă, dar nu este. Acel fișier, numit de ifconfig-pool-persist, înregistrează ce adresă a avut un nume comun ultima dată, astfel încât pool-ul să poată returna aceeași atunci când este convenabil. Nimic din el nu leagă următoarea conexiune de acel număr.

Executați verificările de mai jos în ordine. Fiecare fie confirmă mecanismul, fie vă spune să vă opriți și să reparați o intrare.

La ce servește fișierul de persistență

Fișierul există pentru a menține adresele stabile între reporniri, ceea ce face reconectările mai prietenoase și jurnalele mai ușor de citit. Este citit ca istoric și scris ca istoric, iar calea de alocare rămâne liberă să aleagă altă adresă atunci când indiciul nu se potrivește: alt pool, o alocare conflictuală sau un client care a sosit după ce pool-ul s-a umplut. De aceea o modificare manuală poate părea perfectă în fișier și nu schimbă nimic în conexiune. Tratați-l ca un cache al deciziilor trecute, nu ca sursă de politică.

Dacă aveți nevoie de o adresă anume pentru un client anume, mecanismul documentat este ifconfig-push, iar el aparține configurației care deține acel client.

Verificați că este selectat clientul corect

O alocare explicită este căutată după numele comun al clientului, așa că un fișier numit pentru identitatea greșită pur și simplu nu este citit niciodată. Confirmați ce consideră serverul a fi numele acelui client, mai ales acolo unde username-as-common-name îl schimbă după autentificare. Apoi confirmați că numele fișierului corespunde exact acelei valori, inclusiv majusculele și minusculele.

Luați în considerare concurența cât timp sunteți aici. Dacă duplicate-cn este permis, mai multe dispozitive pot prezenta aceeași identitate, iar o adresă fixă nu poate fi unică pentru toate. Decideți dacă adresa fixă merită refuzarea sesiunilor simultane pentru acea identitate, deoarece aceste două cerințe nu pot fi îndeplinite simultan.

Verificați că numerele corespund topologiei

Sensul argumentelor depinde de topologia tunelului, și aici un exemplu copiat face cel mai mult rău. În vechea aranjare net30 fiecare client ocupă un bloc de patru adrese, așa că push-ul furnizează o pereche de adrese. În topologia de subrețea clientul primește o adresă plus masca pool-ului, iar forma de pereche este greșită. Citiți topologia din configurația care rulează înainte de a scrie linia.

# /etc/openvpn/ccd/partner-a   (subnet topology)
ifconfig-push 10.44.0.61 255.255.255.0

Verificați adresa față de orice altceva ar putea să o dețină: o altă alocare explicită, intervalul pool-ului dinamic și orice rută statică ce presupune un host fix. O adresă care se suprapune cu pool-ul va funcționa până când pool-ul o dă altcuiva, iar acea defecțiune va părea aleatorie.

Verificați rezultatul pe o conexiune nouă

O sesiune existentă păstrează adresa care i s-a dat, așa că singurul test semnificativ este o conexiune nouă. Deconectați clientul, reconectați și citiți adresa pe care a primit-o efectiv împreună cu rutele care au venit cu ea. Dacă adresa este încă dinamică, alocarea nu a fost aplicată, iar pasul următor este căutarea în configurație, nu o altă modificare în fișierul de istoric.

Păstrați dovezile împreună: numele clientului, fișierul care s-a potrivit, adresa alocată și pool-ul din care a venit.

În sfârșit, o adresă fixă de tunel nu este o acreditare a dispozitivului. Ea marchează un loc în planul de adrese, în timp ce autentificarea se sprijină în continuare pe certificat și pe cont. Confundarea celor două transformă un conflict de adrese într-o presupunere de securitate pe care nimeni nu a scris-o.