Client VPN portabil fără drepturi de administrator: ce încă se strică

Portabil descrie instalatorul, nu kernelul. Un client poate veni ca un singur executabil pe un stick USB și tot are nevoie de un dispozitiv de tunel, de o intrare în tabela de rute și de o scriere în resolver înainte ca primul pachet să se miște. Pe care dintre cele trei vă lasă mașina țintă să le atingeți decide dacă acea compilare funcționează acolo deloc. Testele de mai jos răspund la întrebare în ordinea în care clientul le va întâlni.

Portabil acoperă trei promisiuni diferite, și doar una este gratuită

Fără instalator înseamnă că furnizorul nu a înregistrat un serviciu, nu a livrat un dezinstalator și nu a adăugat o intrare în meniu. Fără administrator înseamnă că un cont obișnuit poate porni clientul și finaliza o conexiune. Fără modificări la gazdă înseamnă că mașina arată identic după ce ieșiți. Paginile de descărcare care spun portabil promit de obicei doar prima dintre acestea, iar celelalte două sunt locul unde implementările eșuează. O compilare poate fi portabilă și în sensul strict: rulează de pe medii doar-citire fără nicio scriere de fișiere punct, ceea ce încă nu spune nimic despre stiva de rețea.

Promisiunile scumpe sunt a doua și a treia. Un singur executabil care are nevoie de un adaptor, de o rută sau de o scriere în resolver cere sistemului de operare o autoritate pe care eticheta portabil nu a acoperit-o niciodată.

Găsiți ajutorul privilegiat pe care clientul îl va apela

Aproape niciun client VPN nu mută pachete de unul singur. În Windows calea datelor trece prin filtrele WFP și Base Filtering Engine, în macOS printr-un furnizor NetworkExtension pe care utilizatorul îl aprobă în Setările sistemului, iar în Linux printr-un dispozitiv tun plus stiva de rutare. Binarele pe care le-ați copiat sunt o suprafață de control pentru aceste componente, nu un substitut al lor. Întrebați ce componentă așteaptă clientul, apoi confirmați că este instalată, rulează și poate fi folosită de contul dumneavoastră.

Linux este cel mai ușor loc pentru a demonstra acest lucru, pentru că verificarea este un singur apel de sistem. Deschiderea /dev/net/tun și cererea unui dispozitiv de la kernel necesită CAP_NET_ADMIN, iar documentația kernelului despre TUN/TAP precizează atât regula de proprietate, cât și capacitatea. Rulați testul cu contul care va porni clientul, nu ca root.

ls -l /dev/net/tun
ip tuntap add dev vpntest mode tun
ip link delete vpntest

O eroare de permisiuni pe linia din mijloc este răspunsul pe care îl căutați: acest cont nu poate crea o interfață de tunel, așa că orice client din spațiul utilizatorului care are nevoie de una eșuează la conectare, nu la descărcare. Ultima linie elimină dispozitivul de test și nu afișează nimic când funcționează. Dacă ambele linii reușesc, gazda nu a schimbat nimic permanent.

Testați modificările de rută și de resolver înainte de prima conexiune

Tunelul divizat transformă o conexiune într-o decizie de rutare, în timp ce un tunel complet o transformă într-o înlocuire a rutei implicite. Ambele sunt scrieri în stiva de rețea a gazdei, și ambele eșuează pentru un cont fără privilegii chiar și atunci când clientul pornește curat. Resolverul este a treia scriere, iar pe gazdele cu systemd este de obicei cel care se strică ultimul. Această ordine contează când decideți unde cheltuiți o instalare ridicată.

Un test de rută are nevoie de o destinație care chiar vă pasă, așa că înlocuiți substituentul de mai jos cu o subrețea din propriul profil. Numele dispozitivului trebuie să existe pentru ca ruta să se poată atașa de ceva.

ip route add 10.20.0.0/16 dev vpntest
ip route del 10.20.0.0/16
resolvectl query intranet.example.internal

Dacă prima linie returnează RTNETLINK answers: Operation not permitted, contul nu poate instala ruta privată cerută de profil. A doua linie demonstrează același drept invers, ceea ce contează pentru că un client care poate adăuga rute dar nu le poate elimina lasă în urmă un tabel stricat. Apoi interogarea resolverului arată dacă numele private se rezolvă prin tunel sau se scurg către resolverul în care gazda are deja încredere.

Rulați toate trei cât timp dispozitivul de test încă există, apoi ștergeți-l. O rută care indică un dispozitiv dispărut este cel mai frecvent motiv pentru care un laptop pierde conectivitatea după o conexiune eșuată.

Decideți ce trebuie să supraviețuiască sesiunii

Ștergerea folderului nu este un plan de curățare. Adaptoarele, rutele, setările resolverului, certificatele de încredere și acreditările stocate pot fiecare supraviețui procesului, iar un serviciu la pornire poate restabili unele dintre ele fără să întrebe. Notați ce are voie clientul să lase în urmă înainte de a-l rula, nu după prima deconectare eșuată.

Regula practică este să faceți o instantanee a celor trei suprafețe pe care urmează să le schimbați și să le comparați după aceea. Înregistrați interfețele, tabelul principal de rutare și starea resolverului înainte de prima conexiune, apoi repetați aceleași trei citiri după ce clientul a ieșit.

ip -brief addr show
ip route show table main
resolvectl status

Tot ce apare în a doua captură și lipsește din prima are nevoie de un proprietar. Fie clientul îl elimină la ieșire, fie îl eliminați dumneavoastră cu aceleași comenzi care l-au creat, iar acea eliminare aparține notițelor de implementare, nu memoriei cuiva despre ce s-a întâmplat. În Windows citirile echivalente sunt Get-NetAdapter, Get-NetRoute și Get-DnsClientServerAddress, care nu necesită ridicare dar arată aceleași resturi.