O singură autentificare VPN pe un PC partajat: cine altcineva primește ruta?

Partajarea unei stații de lucru ridică o întrebare la care un laptop cu un singur utilizator nu trebuie să răspundă niciodată: după ce o persoană autentifică tunelul, cine altcineva îl poate folosi? Autentificarea identifică un subiect, iar ruta pe care o instalează descrie un domeniu, și acestea două nu sunt același obiect. Între ele se află sistemul de operare, configurația clientului și ceea ce serviciul privat cere de la sine. Compararea punctelor de aplicare este singura cale de a răspunde fără a ghici.

O autentificare, mai multe domenii

Autentificarea răspunde cine a fost admis. Ruta răspunde ce pachete pot ieși prin tunel. Autorizarea răspunde ce serviciu va accepta conexiunea rezultată, și niciuna dintre cele trei nu o implică pe următoarea.

Un tunel pentru întregul host este valoarea implicită obișnuită și face diferența evidentă. Ruta stă în tabela nucleului, așa că orice proces care folosește acea tabelă poate ajunge la rețeaua privată, inclusiv unul pornit de un utilizator care nu a văzut niciodată fereastra VPN. Nu este un defect al tunelului; asta înseamnă o rută la nivel de sistem. Serviciul privat poate totuși refuza conexiunea, motiv pentru care accesibilitatea și permisiunea au nevoie de răspunsuri separate.

Scrierea celor patru întrebări înainte de test împiedică revizuirea să se reducă la una dintre ele.

Unde se află de fapt granița

Patru aranjamente acoperă majoritatea mașinilor: un tunel pentru întregul host, o conexiune per utilizator, o listă de aplicații permise și un spațiu de nume de rețea sau o mașină virtuală separate.

Fiecare așază punctul de aplicare în alt loc, iar diferențele contează mai mult decât etichetele. Conexiunea per utilizator este aplicată de permisiunile profilului, nu de ecranul de conectare al desktopului. Lista de aplicații permise este aplicată în interiorul clientului, care decide ce va transporta. Un spațiu de nume sau o VM aplică la granița interfeței, astfel încât un proces din interior nu vede deloc ruta hostului. Numărul de ecrane de conectare de pe mașină nu spune nimic despre niciunul dintre ele.

Citirea tabelului rând cu rând arată că întrebarea reală nu este dacă există izolare, ci unde este implementată.

Comparați patru puncte de aplicare

În Linux tabela de rutare este primul lucru de inspectat, fiindcă un tunel pentru întregul host apare acolo, iar un spațiu de nume nu. Rularea căutării ca al doilea utilizator este pasul pe care oamenii îl sar; răspunsul diferă de cel obținut ca ei înșiși, și asta explică raportul.

Următoarele două verificări privesc politica, nu rutarea. O regulă de firewall care corespunde unui UID se aplică traficului generat local, deci poate separa doi utilizatori pe un host chiar când amândoi partajează ruta. Un profil de conexiune cu o listă explicită de permisiuni este aplicat de managerul de rețea la activare. Niciuna dintre verificări nu cere modificarea tunelului, de aceea merită făcute înainte de orice reproiectare.

ip route get 10.40.2.10
sudo -u bob ip route get 10.40.2.10
nmcli connection show vpn-work | grep -i permission
sudo nft list ruleset | grep -n skuid

Dacă a doua căutare arată ruta tunelului, granița nu este acolo unde proiectul presupunea.

Regulile sesiunilor simultane sunt un control separat

Gateway-urile limitează adesea câte sesiuni poate ține un cont, iar acea limită nu are nimic de-a face cu utilizatorii locali. Restrânge contul, așa că o a doua persoană care se conectează cu aceleași credențiale poate încheia tunelul primei persoane.

Citiți eșecul înainte de a presupune o problemă locală de izolare. O limită de sesiuni produce o deconectare la gateway, în timp ce o problemă de domeniu produce un tunel funcțional care pur și simplu nu transportă traficul celuilalt utilizator. Aceste două simptome duc la corecturi complet diferite. Păstrați mesajul exact al clientului, fiindcă de obicei numește regula. Cereți proprietarului profilului fluxul de lucru aprobat în loc să ocoliți limita.

O mașină virtuală nu scutește pe nimeni de acea regulă și adaugă propriul design de rețea și de credențiale.

Testați contextul care vă interesează

Testați utilizatorul și aplicația prevăzute, apoi testați un context care ar trebui refuzat. O revizuire care dovedește doar că parola originală funcționează a testat autentificarea și nimic altceva.

sudo -u bob curl -sS -m 5 https://intranet.internal/health
wg show
ss -tnp | grep -E ':443|:51820'

Notați punctul de aplicare lângă fiecare rezultat: tabela de rutare, o regulă UID, o permisiune de profil sau politica de sesiuni a gateway-ului. Acea înregistrare face următoarea modificare verificabilă. Împiedică și redeschiderea aceleiași întrebări de fiecare dată când cineva observă un al doilea ecran de conectare. Accesibilitatea nu este autorizare, și niciuna dintre ele nu este izolare.