OpenVPN pe Windows: pornirea automată a tunelului și păstrarea rutelor

Aici se încurcă două cerințe: tunelul ar trebui să urce înainte ca cineva să se conecteze, iar traficul către un al doilea site ar trebui să îl urmeze. Sunt probleme separate cu mecanisme separate. Pornirea serviciului o decide pe prima, iar durata de viață a rutei pe a doua. Rezolvarea uneia o lasă pe cealaltă exact unde era.

Primul pas: puneți profilul acolo unde îl caută serviciul

Serviciul Windows citește profiluri dintr-un director fix, iar GUI citește din același loc, așa că un profil care funcționează la import poate rămâne invizibil la pornire. Puneți fișierele .ovpn în directorul config al instalării, care se află de obicei sub Program Files. Un profil lăsat în folderul Downloads al unui utilizator nu intră deloc în sfera serviciului.

Instrucțiunile mai vechi indică un folder config-auto, pe care unele build-uri din epoca 2.5 îl respectau, iar versiunile ulterioare nu. De aceea o actualizare poate transforma o pornire automată funcțională în tăcere, fără nimic în jurnal despre acreditări. Confirmați ce director citește efectiv build-ul instalat înainte de a muta orice fișier.

Cu mai multe profiluri pe o mașină, dați fiecăruia un adaptor cu nume prin dev-node. Altfel concurează pentru aceeași interfață, iar al doilea eșuează într-un mod care arată ca o problemă de acreditări.

Al doilea pas: porniți serviciul, nu pictograma din tavă

Setarea serviciului OpenVPN pe Automatic îl face să pornească la boot fără autentificare. Acesta este mecanismul, iar pictograma din tavă nu face parte din el. Când serviciul deține conexiunea, GUI poate să nu afișeze nici pictogramă, nici stare, ceea ce este de așteptat, nu o defecțiune.

Consecința este că deconectarea înseamnă oprirea serviciului, nu clic pe Disconnect. Spuneți-i celui care întreține mașina, altfel primul apel la suport va fi despre o pictogramă lipsă.

Verificați dacă contul serviciului poate citi profilul și materialul cheii. O problemă de permisiuni la pornire arată în jurnal exact ca o autentificare eșuată.

Al treilea pas: legați ruta de tunel

O intrare persistentă este instrumentul greșit aici. Adăugarea unei rute cu -P o face să supraviețuiască repornirilor și, mai rău, să supraviețuiască închiderii tunelului. Cu VPN-ul oprit, prefixul indică în continuare o poartă care nu mai există, așa că gazda nu poate ajunge la acea destinație până când cineva nu șterge intrarea.

Trei alternative se comportă corect. Împingeți ruta de pe server, care o adaugă la conectare și o elimină la deconectare. Adăugați-o într-un script route-up care citește route_vpn_gateway, astfel încât următorul salt să vină din tunelul negociat. Sau folosiți Add-VpnConnectionRoute cu un profil VPN nativ Windows, care leagă prefixul de acea conexiune.

Când serverul oferă mai mult decât are nevoie acest site, route-nopull refuză rutele împinse și lasă tabelul complet local. Asta se potrivește unui profil partajat ai cărui utilizatori nu trebuie să primească o rută implicită corporativă.

Al patrulea pas: supraviețuiți unei porniri la rece

Pornirea serviciului înainte de a exista stiva de rețea produce o singură încercare eșuată și nicio repetare. Setarea pe Automatic (Delayed Start), sau adăugarea unei dependențe de serviciul de rețea, elimină acea cursă. Apoi repetați testul de pornire și verificați că o a doua încercare nu mai este necesară.

Modificările de rută și adaptor necesită drepturi de administrator. O comandă rapidă de pornire pentru fiecare utilizator nu le are, așa că un script care funcționează dintr-un shell ridicat poate să nu facă nimic în tăcere la conectare. Programați-l ca sarcină cu cele mai înalte privilegii, sau lăsați serviciul să preia modificarea. Apoi testați-l ca utilizatorul care se va conecta efectiv.

Testați secvența pe care o implementați efectiv, nu pe cea pe care o puteți declanșa manual. O pornire la rece este singurul test care exersează ordinea.

Al cincilea pas: verificați fără GUI

După o repornire și o conectare, verificați trei lucruri fără a deschide GUI. Adaptorul trebuie să aibă o adresă,tabelul de rute trebuie să arate prefixul site-ului cu poarta tunelului ca următor salt, iar un ping către o adresă din partea cealaltă trebuie să răspundă. Fiecare verificare corespunde unui mecanism diferit din pașii de mai sus.

Când adaptorul nu apare niciodată, suspectul este driverul, nu profilul. Acele două defecțiuni nu seamănă deloc în jurnal, și doar una dintre ele răspunde la reinstalarea software-ului.