Două gateway-uri, un VPN: de ce OpenVPN alege uplink-ul greșit

Două uplink-uri, un tunel, iar traficul iese prin cel pe care nu l-ați ales. Subrețelele private sunt accesibile, jurnalul raportează o conexiune reușită, iar legătura măsurată este cea care îl transportă. Nimic în ieșirea OpenVPN nu menționează un gateway, pentru că clientul nu a ales niciodată unul. A deschis un socket către o adresă îndepărtată și a lăsat nucleul să decidă cum se ajunge la acea adresă.

Adresa tunelului nu este punctul final

În fiecare sesiune există două căi diferite. Calea exterioară transportă traficul criptat către adresa publică a serverului. Calea interioară transportă tot ce împinge serverul în tunel, iar regulile de rutare pentru una nu au efect asupra celeilalte.

Intrarea remote din profil numește destinația exterioară, deci aceea este adresa care trebuie fixată. Este și valoarea care se schimbă atunci când un nume de gazdă se rezolvă diferit sau profilul listează mai multe remote.

Găsiți adresa pe care clientul a apelat-o de fapt

Citiți socketul activ, nu fișierul de configurare. Tabelul de socketuri arată peer-ul la care procesul s-a conectat de fapt, iar aceea este valoarea cu care trebuie să corespundă excepția. Un profil poate fi editat după începerea sesiunii, iar socketul este singura dovadă a ceea ce a fost apelat:

ss -tunp | grep -i openvpn
journalctl -u openvpn-client@work --no-pager | grep -i "Peer Connection Initiated"

Linia de jurnal indică adresa și portul peer-ului la momentul conectării. Dacă nu corespunde profilului, ceva din fața clientului rescrie destinația înainte ca conexiunea să înceapă.

Verificați și familia de adrese. Un profil cu două stive se poate conecta prin IPv6 în timp ce excepția dumneavoastră acoperă doar IPv4, iar traficul urmează atunci o regulă diferită de cea pe care ați scris-o. Același lucru este valabil pentru un proxy care răspunde în numele punctului final. Ambele cazuri produc un tunel care funcționează în timp ce ruta dumneavoastră nu face nimic.

Fixați punctul final și citiți ordinea politicii

O rută de gazdă este mai specifică decât orice rută implicită. De aceea un /32 pentru adresa peer-ului câștigă în tabelul care îl conține. Forma obișnuită numește explicit gateway-ul și dispozitivul:

ip route add 203.0.113.40/32 via 192.168.10.1 dev eth0

Acea rută ajută doar dacă căutarea ajunge la acel tabel. Regulile de politică sunt evaluate în ordine și prima potrivire decide, deci o regulă care trimite totul într-un al doilea tabel ocolește ruta dumneavoastră de gazdă din main. Citiți regulile înainte de a presupune că ruta este autoritativă:

ip rule show
ip route get 203.0.113.40

Întrebați a doua comandă cu aceeași adresă sursă sau marcaj pe care le folosește clientul când politica depinde de ele. Raportează ruta pe care nucleul ar alege-o, ceea ce este o dovadă despre căutare și nu o dovadă că socketul activ folosește acea cale.

Când punctul final se mută

Un nume de gazdă care se rezolvă la mai multe adrese invalidează un /32 permanent de îndată ce răspunsul se schimbă. Un profil cu mai multe linii remote are aceeași problemă, pentru că clientul poate ateriza pe oricare dintre ele. Reîmprospătați ruta din propriile cârlige de ciclu de viață ale clientului în loc să o adăugați manual. Un script up care citește peer-ul negociat și instalează ruta de gazdă menține excepția aliniată cu realitatea, iar un script down corespunzător o elimină.

Înregistrați reîmprospătarea în același loc cu restul configurației de rutare a gazdei. O rută care există doar până la următoarea repornire este un test, nu o corectare.

Țineți politica interioară separată

Mutarea căii exterioare nu acordă acces la o nouă subrețea privată și nu schimbă destinațiile pe care serverul le împinge în tunel. Ruta stratului inferior alege firul; rutele împinse aleg ce intră în tunel. Păstrarea acestor două decizii separate face împărțirea previzibilă.

Dacă scopul este doar să țineți traficul criptat departe de o legătură măsurată, lăsați ruta implicită în pace și adăugați singura excepție de gazdă. Înlocuirea rutei implicite a întregii mașini pentru a muta o singură conexiune VPN strică orice altă aplicație de pe gazdă.

Confirmați rezultatul cu două observații independente: adresa locală și dispozitivul socketului, și ruta către care se rezolvă destinația privată. Când ambele corespund intenției dumneavoastră, împărțirea este reală. Manualul OpenVPN 2.6 acoperă opțiunile remote și de legare locală care decid către ce adresă apelează clientul.