ifconfig-push: adresă de peer în net30 sau mască de subrețea în subnet?

Clienții dinamici se conectează și rutează bine, dar singurul client cu adresă fixă nu ajunge deloc la server. Nimic din firewall nu s-a schimbat, iar linia CCD pare plauzibilă. Cauza obișnuită este un al doilea argument scris pentru o topologie TUN diferită de cea pe care rulează serverul. Defecțiunea este tăcută: clientul pornește cu o adresă și serverul acceptă conexiunea, dar niciun trafic nu trece.

În net30 acel câmp este o adresă de peer; în subnet este o mască de subrețea. Cele două forme sunt alternative, niciodată o secvență.

Cele două forme, alăturate

Într-o implementare net30 tradițională fiecare client deține un bloc /30: o adresă de rețea, două adrese utilizabile și o adresă de broadcast. ifconfig-push preia adresa clientului și adresa peerului, iar peerul este cealaltă adresă utilizabilă din același bloc, folosită de partea de server a legăturii punct-la-punct.

# net30: client address and its peer
ifconfig-push 10.99.0.6 10.99.0.5
# topology subnet: client address and the pool netmask
ifconfig-push 10.99.0.20 255.255.255.0

Sub topology subnet clientul împarte o subrețea cu serverul, iar aceeași directivă preia o adresă și o mască de subrețea. Adresa proprie a serverului vine din directiva server, nu din al doilea câmp. Amestecarea formelor produce un client care crede că este pe o legătură punct-la-punct, în timp ce serverul îl rutează ca gazdă de subrețea, sau invers. De aceea o mască de subrețea nu trebuie niciodată asociată cu net30.

Ambele linii din bloc sunt linii separate pentru un fișier CCD. Un client primește exact una dintre ele.

Citiți topologia pe care serverul o rulează de fapt

Citiți configurația în execuție, nu valoarea implicită a pachetului, pentru că topologia poate fi fost stabilită cu ani în urmă și copiată mai departe. Căutați topology subnet sau absența lui, apoi verificați cum linia server alocă adrese. O configurație care nu menționează niciodată topologia nu este la fel cu una care stabilește subnet.

Apoi citiți setările primite de client. Adresa, masca și peerul pe care le raportează vă spun ce interpretare a aplicat serverul.

Țineți adresa fixă în afara pool-ului dinamic

O adresă fixă trebuie să stea în afara pool-ului dinamic, altfel doi clienți pot primi aceeași adresă. Cu topologia subnet, nopool pe linia server suprimă pool-ul automat, iar un interval explicit ifconfig-pool definește ce primesc clienții dinamici.

dev tun
topology subnet
server 10.99.0.0 255.255.255.0 nopool
ifconfig-pool 10.99.0.100 10.99.0.210 255.255.255.0
client-config-dir /etc/openvpn/ccd

Serverul ia 10.99.0.1 pentru sine, iar adresa fixă a clientului stă în afara intervalului pool-ului. Fișierul CCD este numit după identitatea efectivă a clientului, nu după numele fișierului de profil, și nu primește o extensie suplimentară. Dacă username-as-common-name este activ, numele de utilizator autentificat este identitatea de potrivit. Două dispozitive care împart o identitate vor împărți și adresa fixă, ceea ce este o problemă de politică, nu de rutare.

Verificați atribuirea pe care clientul a primit-o de fapt

Reconectați clientul dorit și confirmați ce fișier CCD a fost selectat înainte de a verifica orice altceva. Apoi verificați adresa, masca sau peerul și ruta înapoi la server. Un client care arată o adresă de peer într-o implementare subnet folosește încă forma greșită.

Schimbarea topologiei afectează fiecare client și fiecare suprascriere, așa că tratați-o ca o migrare, nu ca o reparație a unui client. Corectarea liniei statice pentru a se potrivi topologiei deja folosite este de obicei schimbarea mai mică. Referința server-options documentează ajutorul și suprascrierile specifice clientului.