Cârlig de client sau cârlig de server? Unde rulează un script OpenVPN

Sarcina este clară: când un laptop se conectează, ceva de pe laptop ar trebui să se schimbe. Configurația care se editează aparține serverului, și exact acolo se rupe presupunerea. O cale într-un fișier de server indică un fișier de pe acel server, iar nicio cantitate de push nu schimbă al cui proces îl execută. Alegerea între cele două cârlige este în principal decizia privind mașina care deține lucrarea și acceptarea limitelor care decurg.

Două mașini, două întrebări la care trebuie răspuns mai întâi

Întrebați unde trebuie să aibă loc schimbarea de stare, apoi întrebați ce eveniment îi corespunde. Dacă schimbarea este o autorizare per utilizator sau o decizie de configurare per client, ea aparține locului unde directorul de utilizatori este cunoscut: serverul. Dacă schimbarea este o rută, o setare de resolver sau un ajutor local pe un punct final, aparține punctului final, și doar punctul final o poate face.

Răspunsul la aceste două întrebări în ordine inversă este felul în care oamenii ajung să încerce să împingă un fișier batch către un laptop Windows. Serverul știe cine s-a conectat; laptopul știe cum arată propria stivă de rețea. Niciunul nu are informațiile celuilalt, iar încercarea eșuează de obicei în liniște, nu cu o eroare clară.

Înaintea ambelor merită o a treia întrebare: platforma oferă măcar cârligul dorit? Un aparat care își generează singur configurația poate să nu ofere aceleași nume de evenimente, iar un client desktop care importă un fișier .ovpn nu este neapărat același client pentru care a fost scris fișierul. Confirmarea platformei mai întâi vă scutește de a proiecta în jurul unui cârlig care nu există acolo. Vă mai spune și ce documentație se aplică de fapt mașinii din fața dumneavoastră.

Opțiunea de pe partea serverului: un eveniment per conexiune

Un script client-connect rulează în contextul procesului serverului când se conectează un client autentificat și primește detalii de conexiune documentate, cum ar fi common name și adresa alocată. Este locul potrivit pentru a scrie un fragment de configurare per client, a aplica o decizie de politică sau a înregistra starea pe care o deține serverul.

Distincția pe care oamenii o ratează este diferența dintre acel cârlig și un cârlig up al serverului. Cârligul up se declanșează când serverul își deschide dispozitivul de tunel, ceea ce pe un server cu mai mulți clienți se întâmplă o singură dată la pornirea demonului. Nu este un eveniment per autentificare, iar codul plasat acolo rulează la pornirea serviciului, nu când se conectează utilizatorii.

Pe un aparat cu interfață web, folosiți mecanismul de extensie acceptat în loc să editați fișierele demon generate. Fișierele generate sunt rescrise la următoarea salvare, iar rescrierea vă elimină în liniște modificarea în cel mai rău moment posibil. Păstrați o copie a textului extensiei în afara aparatului, pentru ca o actualizare de firmware să nu piardă și intenția.

Opțiunea de pe partea clientului: muncă ce trebuie să ruleze local

Un client din comunitate poate rula un script local când dispozitivul de tunel apare și din nou când se instalează rutele. Sunt două momente diferite, iar alegerea greșită produce cursa clasică în care un ajutor pornește înainte să existe ruta de care depinde.

Ajutorul trebuie să existe pe acel client, să fie lizibil și executabil pentru contul care rulează clientul și să fie permis de o setare script-security explicită. Un script care funcționează când lansați clientul ca administrator nu vă spune nimic despre un serviciu dinaintea autentificării sau despre sesiunea altui utilizator.

Și denumirile contează. Cârligul up corespunde creării dispozitivului, iar route-up instalării rutelor, dar o sarcină ce are nevoie de o rețea privată accesibilă trebuie să verifice accesibilitatea, nu să presupună că crearea dispozitivului înseamnă că fiecare rută, intrare de resolver și aplicație sunt gata.

De ce împingerea codului executabil nu este printre opțiuni

Opțiunile trimise prin push sunt limitate în mod deliberat, iar opțiunile care execută scripturi sunt printre categoriile pe care serverul nu are voie să le transmită. Această restricție există pentru că alternativa ar permite unui server compromis sau configurat greșit să ruleze comenzi arbitrare pe fiecare client care se conectează vreodată.

Activarea execuției de scripturi local nu schimbă asta. Setarea dumneavoastră script-security permite scripturile locale pe care le-ați ales; nu autorizează serverul să furnizeze altele noi.

Dacă scopul este doar instalarea de rute VPN, folosiți configurația de rute acceptată în loc să inventați o schemă de execuție la distanță. Dacă scopul chiar necesită cod local, distribuiți-l prin instrumentele de gestiune a punctelor finale ale organizației și revizuiți-l ca orice alt software care rulează cu privilegiile utilizatorului.

Ce să verificați înainte de a avea încredere în oricare dintre cârlige

Notați patru lucruri pentru fiecare cârlig: mașina, numele evenimentului, contul sub care rulează și schimbarea de stare pe care ar trebui să o producă. Apoi testați conexiunea, o reconectare și calea de curățare, pentru că un cârlig care pierde stare la reconectare este mai rău decât unul care nu a rulat niciodată.

Testați sub contul care îl va executa efectiv, în momentul în care va fi executat efectiv. Manualul openvpn(8) documentează ambele familii de cârlige și restricțiile push; platforma pe care implementați documentează dacă le expune sau nu. Un script care reușește într-un terminal de administrator interactiv este o ipoteză, nu o verificare.