Conta VPN compartida: un límite de dispositivos non é illamento de clientes

Oito conexións simultáneas é un número dunha páxina de licenza, e non di nada sobre o que poden facerse eses oito dispositivos entre eles. Un inicio de sesión compartido pode convivir con chaves por sesión, e tamén pode convivir cunha pasarela que reenvía de boa gana o tráfico dun cliente a outro. O erro é tratar a conta como unha fronteira de seguridade. Faga mellor catro preguntas separadas: que se comprou, que protexe o túnel, que pode cruzar entre pares e que pode tombar a ligazón local.

Que promete realmente un permiso de conexións

Un límite de dispositivos conta cantas sesións aceptará o provedor por unha subscrición. É un control comercial e operativo, non unha declaración sobre identidade ou illamento. Algúns provedores emiten un certificado distinto por dispositivo baixo unha soa conta; outros reutilizan unha única credencial en cada conexión. A diferenza aparece ao revogar, porque as credenciais separadas permítenlle cortar un dispositivo e unha compartida non lle deixa esa opción.

Lea como emite o provedor as credenciais antes de supoñer nada sobre a separación de chaves. O nome da conta non revela nada diso.

Comprobe se a pasarela reenvía entre clientes

O alcance entre pares é unha decisión do lado do servidor. En OpenVPN o interruptor pertinente está ausente salvo que apareza na configuración, pero a descarga moderna do plano de datos cambia onde se aplica a regra.

grep -n "client-to-client" /etc/openvpn/server.conf
iptables -A FORWARD -i tun0 -o tun0 -j DROP

Unha configuración sen esa directiva deixa o tráfico entre pares á devasa do anfitrión, que aínda pode permitilo. Cando a descarga está activa, o núcleo encárgase da interface do túnel en lugar do proceso de espazo de usuario, así que verifique os contadores de regras en vez de confiar no ficheiro. Bloquear o tráfico reenviado entre enderezos do túnel illa os clientes sen tocar o seu acceso á pasarela. Confírmeo cunha proba dun cliente a un servizo noutro, tanto antes como despois da regra.

Proteja a sesión antes que os pares

A protección do túnel e o acceso entre pares son propiedades distintas, e un cifrado forte non implica illamento. En modo TLS cada cliente deriva as súas propias chaves de sesión, así que un cliente non pode ler o tráfico doutro aínda que a pasarela o retransmita. O antigo esquema de chave estática comparte unha soa chave entre todos, por iso reutilizar alí un inicio de sesión ten consecuencias moito peores. Inspeccione o modo configurado e non a páxina de mercadotecnia, e logo xulgue se compartir a conta encaixa cos datos en xogo.

A autenticación do servizo en cada anfitrión segue importando, porque o túnel só demostra que un cliente chegou á rede, non que deba chegar a un daemon concreto.

Os fallos do Wi-Fi local non son compromisos do VPN

Unha conexión caída demostra que fallou a ligazón local, non que alguén rompese o túnel. As interferencias, unha concesión DHCP perdida e un traspaso de itinerancia rematan unha sesión sen tocar credenciais nin texto cifrado. Trate a desconexión como un achado de dispoñibilidade e mantéña á parte dos achados de confidencialidade e acceso entre pares. Onde a rede local non é fiable, protexa o tráfico de extremo a extremo en lugar de apoiarse só no túnel.

Anote as catro respostas: permiso, modelo de chaves, política entre pares e dependencia da ligazón local. Ese rexistro converte unha preocupación vaga sobre unha conta compartida en controis concretos.