Cont VPN partajat: o limită de dispozitive nu este izolare a clienților
Permisiunea pentru opt dispozitive nu spune nimic despre izolare sau gestionarea cheilor. Separați limitele contului, protecția tunelului, redirecționarea între parteneri și Wi-Fi-ul local.
Opt conexiuni simultane este un număr dintr-o pagină de licență și nu spune nimic despre ce pot face aceste opt dispozitive unul altuia. O autentificare partajată poate coexista cu chei pe sesiune și poate coexista și cu o poartă care redirecționează bucuros traficul unui client către altul. Greșeala este să tratăm contul ca o frontieră de securitate. Puneți în schimb patru întrebări separate: ce s-a cumpărat, ce protejează tunelul, ce poate trece între parteneri și ce poate doborî legătura locală.
Ce promite de fapt o permisiune de conexiuni
O limită de dispozitive numără câte sesiuni va accepta furnizorul pentru un abonament. Este un control comercial și operațional, nu o declarație despre identitate sau izolare. Unii furnizori emit un certificat separat pentru fiecare dispozitiv sub un singur cont; alții refolosesc o singură acreditare la fiecare conexiune. Diferența apare la revocare, pentru că acreditările separate vă permit să tăiați un dispozitiv, iar una partajată nu vă lasă această opțiune.
Citiți cum emite furnizorul acreditările înainte de a presupune ceva despre separarea cheilor. Numele contului în sine nu dezvăluie nimic din asta.
Verificați dacă poarta redirecționează între clienți
Accesibilitatea între parteneri este o decizie pe partea serverului. La OpenVPN comutatorul relevant lipsește dacă nu apare în configurație, dar descărcarea modernă a planului de date schimbă locul unde se aplică regula.
grep -n "client-to-client" /etc/openvpn/server.conf
iptables -A FORWARD -i tun0 -o tun0 -j DROPO configurație fără acea directivă lasă traficul între parteneri în seama paravanului gazdă, care îl poate permite în continuare. Când descărcarea este activă, nucleul se ocupă de interfața tunelului în locul procesului din spațiul utilizator, așa că verificați contoarele de reguli în loc să vă încredeți în fișier. Blocarea traficului redirecționat între adresele tunelului izolează clienții fără a atinge accesul lor la poartă. Confirmați cu o probă de la un client la un serviciu de pe altul, atât înainte, cât și după regulă.
Protejați sesiunea înaintea partenerilor
Protecția tunelului și accesul între parteneri sunt proprietăți diferite, iar un cifru puternic nu implică izolare. În modul TLS fiecare client derivă propriile chei de sesiune, așa că un client nu poate citi traficul altuia chiar dacă poarta îl retransmite. Vechiul aranjament cu cheie statică împarte o singură cheie între toți, de aceea refolosirea unei autentificări acolo are consecințe mult mai grave. Inspectați modul configurat, nu pagina de marketing, și apoi judecați dacă partajarea contului se potrivește datelor în cauză.
Autentificarea serviciului pe fiecare gazdă rămâne importantă, pentru că tunelul dovedește doar că un client a ajuns în rețea, nu că ar trebui să ajungă la un anumit demon.
Defecțiunile Wi-Fi locale nu sunt compromiteri ale VPN
O conexiune căzută dovedește că legătura locală a eșuat, nu că cineva a spart tunelul. Interferențele, o concesiune DHCP pierdută și un transfer la roaming încheie o sesiune fără să atingă acreditările sau textul cifrat. Tratați deconectarea ca o constatare despre disponibilitate și țineți-o separată de constatările despre confidențialitate și acces între parteneri. Acolo unde rețeaua locală nu este de încredere, protejați traficul de la un capăt la altul în loc să vă bazați doar pe tunel.
Notați cele patru răspunsuri: permisiune, model de chei, politică între parteneri și dependența de legătura locală. Acea notă transformă o îngrijorare vagă despre un cont partajat în controale concrete.