Compte VPN compartit: un límit de dispositius no és aïllament de clients
Permetre vuit dispositius no diu res sobre l’aïllament ni la gestió de claus. Separeu els límits del compte, la protecció del túnel, el reenviament entre parells i el Wi-Fi local.
Vuit connexions simultànies és un número d’una pàgina de llicència, i no diu res sobre què poden fer-se aquests vuit dispositius entre ells. Un inici de sessió compartit pot conviure amb claus per sessió, i també pot conviure amb una passarel·la que reenvia alegrement el trànsit d’un client a un altre. L’error és tractar el compte com una frontera de seguretat. Feu més aviat quatre preguntes separades: què s’ha comprat, què protegeix el túnel, què pot travessar entre parells i què pot tombar l’enllaç local.
Què promet realment un permís de connexions
Un límit de dispositius compta quantes sessions acceptarà el proveïdor per a una subscripció. És un control comercial i operatiu, no una declaració sobre identitat o aïllament. Alguns proveïdors emeten un certificat diferent per dispositiu sota un sol compte; d’altres reutilitzen una sola credencial per a cada connexió. La diferència apareix en el moment de la revocació, perquè les credencials separades us permeten tallar un dispositiu i una de compartida no us deixa aquesta opció.
Llegiu com emet el proveïdor les credencials abans de suposar res sobre la separació de claus. El nom del compte no en revela res.
Comproveu si la passarel·la reenvia entre clients
L’abast entre parells és una decisió del costat del servidor. A OpenVPN l’interruptor rellevant és absent tret que aparegui a la configuració, però la descàrrega moderna del pla de dades canvia on s’aplica la regla.
grep -n "client-to-client" /etc/openvpn/server.conf
iptables -A FORWARD -i tun0 -o tun0 -j DROPUna configuració sense aquesta directiva deixa el trànsit entre parells al tallafoc de l’amfitrió, que encara pot permetre’l. Quan la descàrrega és activa, el nucli s’encarrega de la interfície del túnel en lloc del procés d’espai d’usuari, així que verifiqueu els comptadors de regles en lloc de confiar en el fitxer. Bloquejar el trànsit reenviat entre adreces del túnel aïlla els clients sense tocar el seu accés a la passarel·la. Confirmeu-ho amb una prova d’un client a un servei d’un altre, abans i després de la regla.
Protegiu la sessió abans que els parells
La protecció del túnel i l’accés entre parells són propietats diferents, i un xifratge fort no implica aïllament. En mode TLS cada client deriva les seves pròpies claus de sessió, així que un client no pot llegir el trànsit d’un altre encara que la passarel·la el retransmeti. L’antic esquema de clau estàtica comparteix una sola clau entre tothom, i per això reutilitzar-hi un inici de sessió té conseqüències molt pitjors. Inspeccioneu el mode configurat i no la pàgina de màrqueting, i després jutgeu si compartir el compte s’adiu amb les dades en joc.
L’autenticació del servei a cada amfitrió encara importa, perquè el túnel només demostra que un client ha arribat a la xarxa, no que hagi d’arribar a un dimoni concret.
Les fallades del Wi-Fi local no són compromisos del VPN
Una connexió caiguda demostra que l’enllaç local ha fallat, no que algú hagi trencat el túnel. Les interferències, una concessió DHCP perduda i un traspàs d’itinerància acaben una sessió sense tocar credencials ni text xifrat. Tracteu la desconnexió com una troballa de disponibilitat i manteniu-la separada de les de confidencialitat i accés entre parells. On la xarxa local no és fiable, protegiu el trànsit d’extrem a extrem en lloc de recolzar-vos només en el túnel.
Anoteu les quatre respostes: permís, model de claus, política entre parells i dependència de l’enllaç local. Aquest registre converteix un neguit vague sobre un compte compartit en controls concrets.