Scripturile pornesc clienții VPN la stratul pe care l-a ales autorul, iar acel strat este rareori cel de care avea nevoie sarcina. Linia de comandă a furnizorului, formatorul sistemului de operare și o intenție de aplicație mobilă se întorc toate în momente diferite din viața conexiunii. Tratează și secretul diferit, iar această diferență decide dacă parola este vizibilă pentru fiecare utilizator de pe mașină. Alegeți stratul înainte de a scrie prima linie a scriptului.

Stratul 1: linia de comandă a furnizorului

Majoritatea clienților desktop livrează o linie de comandă care preia un nume de profil și, mult prea des, o parolă. Vechiul client Cisco accepta un verb connect cu argumente de utilizator și parolă; macOS expune serviciul încorporat prin networksetup; NetworkManager răspunde la nmcli. Aceste apeluri se întorc când comanda se termină, ceea ce nu este același moment cu cel în care tunelul devine utilizabil. Citiți documentația furnizorului pentru versiunea pe care o implementați, pentru că aceste interfețe se schimbă și unele sunt eliminate complet.

nmcli connection up "Work VPN"
networksetup -connectpppoeservice "Work VPN"

Avantajul este că furnizorul își cunoaște propriul depozit de profiluri, astfel încât apelul folosește aceeași configurație pe care ar folosi-o GUI-ul. Dezavantajul este că fiecare furnizor inventează propriile verbe, iar un script scris pentru un client nu se transferă la altul. Considerați acest strat drept calea cea mai scurtă atunci când clientul este fix și versiunea este fixată.

Stratul 2: serviciul propriu al sistemului de operare

În Windows formatorul face parte din sistemul de operare și lucrează pe o intrare din cartea de telefon în locul depozitului de profiluri al furnizorului. Asta îl face mai portabil între clienți și mai ușor de scriptat dintr-un cont de serviciu. Înseamnă și că conexiunea poate exista într-un loc și nu în celălalt, ceea ce îi încurcă pe cei care se uită în lista greșită.

rasdial "Work VPN" user pass
Get-VpnConnection -Name "Work VPN" | Select-Object ConnectionStatus

Folosiți suprafața PowerShell când trebuie să creați sau să eliminați intrarea în loc să o formați. Straturile WMI și cmdlet expun aceleași obiecte sub nume diferite, iar eliminarea este o operațiune separată de deconectare. Un script care doar formează va lăsa intrări învechite după o migrare. Verificați în ce depozit scrie automatizarea dvs. înainte de a promite că curățarea are loc.

Remove-VpnConnection -Name "Old VPN" -Force
Get-VpnConnection

În macOS echivalentul este lista de servicii de rețea, unde un serviciu existent este conectat după nume în loc să fie creat pe loc.

Credențialele se scurg la fiecare strat, așa că alegeți canalul

Tot ce treceți pe linia de comandă apare în tabelul de procese pentru fiecare utilizator local și de obicei supraviețuiește și în istoricul shell-ului. Alternativa susținută de OpenVPN este să citiți secretul dintr-un fișier cu --askpass, iar fișierul în sine are nevoie de permisiuni care corespund încrederii pe care o puneți în acesta. Un pipe cu nume evită scrierea secretului pe disc, dar permite oricărui proces care îl poate deschide să scrie acolo. În Windows, păstrați secretul în managerul de credențiale sau într-un fișier pe care doar contul de serviciu îl poate citi, și niciodată ca literal într-un fișier batch.

openvpn --config /etc/openvpn/work.conf --askpass /etc/openvpn/work.secret --auth-nocache --daemon
ls -l /etc/openvpn/work.secret

Aceeași regulă se aplică tokenurilor și codurilor de unică folosință: dacă automatizarea le necesită, automatizarea are nevoie de un canal care nu este un argument de linie de comandă. Rotiți secretul când schimbați mecanismul, pentru că vechea valoare a stat undeva într-un jurnal. Un script care funcționează și se scurge nu este un script funcțional.

Așteptați starea, apoi supravegheați un singur proprietar

Fiecare dintre aceste apeluri se întoarce înainte ca tunelul să fie gata, așa că interogați starea pe care o expune clientul sau încercați o destinație în interiorul ei cu un timp limită. Copierea fișierelor sau deschiderea unei conexiuni la baza de date imediat după apelul de conectare este o cursă și eșuează intermitent într-un mod care arată ca o defecțiune de rețea.

ip link show tun0
nmcli -t -f GENERAL.STATE connection show "Work VPN"
curl -sS --max-time 5 https://app.internal.example/health -o /dev/null

Deconectarea are aceeași problemă în sens invers: procesul poate ieși înainte ca rutele să fi dispărut. Folosiți cârligele clientului acolo unde există, cum ar fi scripturile up și down ale OpenVPN sau ExecStartPost al unei unități systemd, pentru că rulează în punctul care vă interesează cu adevărat. Cârligele rulează cu privilegiile celui care le-a invocat, așa că un cârlig care repornește rețeaua are nevoie de o regulă explicită în loc de o presupunere. Păstrați exact un proprietar pe durata de viață a conexiunii.

Când doi supervizori pornesc și opresc același profil, rezultatul este o buclă de reconectare care se citește ca o cădere a furnizorului. Runbook-ul se termină când stratul este documentat, secretul are un canal care nu este argv, condiția de așteptare este o verificare de stare cu timp limită și un singur proces deține ciclul de viață.

Articole similare