O sitio só te bloquea coa VPN activada? Isto é o que ve
O bloqueo adoita ser o enderezo de saída, non unha fuga. Comproba a rede desde a que parece chegar o tráfico, o resolutor que un sitio pode rexistrar e o que sabe o código da páxina.
A tenda carga ben na casa e mostra un muro de «tráfico inusual» no momento en que o túnel se levanta. Un foro négase a iniciar a túa sesión, e unha páxina de streaming insiste en que estás nun país que nunca visitaches. Nada diso require software espía. Un sitio ve o enderezo desde o que chegan os teus paquetes, e cunha VPN ese enderezo pertence a un centro de datos en lugar de a unha liña doméstica. A maior parte do que se chama detección de VPN comeza e remata nese único feito, e o resto é inferencia cunha taxa de erro previsible.
O bloqueo comeza por onde parece que veñen os teus paquetes
Cada solicitude leva un enderezo de orixe, e o servidor que a recibe pode consultalo en datos públicos: que rede o anuncia, se esa rede é un provedor de aloxamento, se apareceu en listas de abuso e que país lle asigna o rexistro. Nada diso te identifica, e todo xunto abonda para encasillarte.
Mira o teu propio tráfico como o faría un descoñecido. Dous comandos cobren a maior parte da superficie, e o segundo é o que a xente esquece:
curl -sS https://ipinfo.io/json
dig +short TXT o-o.myaddr.l.google.com @ns1.google.comO primeiro devolve o enderezo de saída, a súa organización e o seu país. O segundo devolve o enderezo do resolutor que chegou ao servidor de nomes de Google, que a miúdo é unha rede distinta da túa saída e é o enderezo que ve un sitio se rexistra datos do lado do resolutor. Cando eses dous pertencen a países distintos, algúns sitios tratan a discrepancia como sospeitosa aínda que non haxa nada malo na túa configuración.
Cando o rexeitamento comeza só despois de que o túnel se levante, sospeita do enderezo de saída antes que de nada máis. Cambia de servidor e volve intentalo antes de tocar o navegador. Un bloqueo que te segue por tres saídas do mesmo provedor ten que ver cos rangos do provedor; un bloqueo que desaparece noutro servidor ten que ver con ese único enderezo.
A zona horaria, a lingua e o reloxo non concordan co enderezo
O código da páxina pode ler a túa zona horaria, as túas preferencias de lingua e a configuración de pantalla sen ningunha petición de permiso. Un navegador que informa da hora de Europa Central mentres a conexión chega dun centro de datos en Singapur é un sinal máis forte que o enderezo só, e é xusto o tipo de discrepancia que a puntuación de fraude está feita para notar.
Intl.DateTimeFormat().resolvedOptions().timeZone
navigator.language
Intl.DateTimeFormat().resolvedOptions().localeEses tres liñas na consola de desenvolvemento dinche que ofrece voluntariamente o teu navegador. Un cliente VPN pode cambiar a túa ruta e nada máis, así que o perfil que levas queda doméstico mentres que a túa saída non o é. A coherencia é o que importa aquí: un portátil configurado na mesma rexión que a saída parece normal, e un que se contradí a si mesmo non.
Tamén é por iso que o fallo é intermitente. A moitos sitios non lles importa, uns poucos póñenlle puntuación, e un sitio de subscrición decide que es un estafador. O cliente funciona correctamente nos tres casos, e por iso a resposta habitual do soporte, «debe ser o teu navegador», é á vez molesta e en parte certa.
O que o código da páxina sabe realmente da túa máquina
JavaScript non ten ningunha API que enumere interfaces de rede. Unha páxina non pode preguntar que enderezos ten o teu portátil, así que a vella afirmación de que un script le o teu enderezo LAN é sobre todo un recordo da época dos complementos, cando os controis ActiveX, os applets de Java e outro código nativo podían facer exactamente iso.
| Signal | What it reveals | Status today |
|---|---|---|
| Source address of the request | Exit network, country, hosting status | Always visible; the main signal |
| Time zone and language | Where the profile claims to be | Readable without permission |
| WebRTC candidates | Local addresses, historically | Host candidates are mDNS-obfuscated by default |
| Interface list | All local addresses | Not available to ordinary JavaScript |
WebRTC é a excepción honesta a «ningunha fuga de enderezos locais». A súa recollida de candidatos expoñía antes enderezos locais a calquera páxina que o pedise, e a solución foi substituír os candidatos de host por nomes mDNS aleatorios. Ese valor predeterminado mantense nos navegadores actuais, pero é unha decisión do navegador e non unha garantía do protocolo, así que unha versión anticuada ou unha configuración endurecida que volva habilitar os candidatos locais aínda pode filtrar. Actualizar o navegador axúdache aquí máis que calquera extensión.
O teu provedor ve os nomes, non os contidos
HTTPS protexe o contido dunha páxina de extremo a extremo, e o operador do túnel que reenvía eses bytes non pode lelos. O operador aínda pode ver a que enderezo contactaches, e na maioría de despregamentos o nome do servidor no handshake, porque o nome ten que ser lexible para que a conexión se dirixa ao sitio correcto. Encrypted Client Hello existe precisamente para ocultar ese campo, e só axuda cando tanto o cliente como o sitio o admiten.
A resolución de nomes é a outra metade. Se o teu provedor tamén fornece o resolutor, ve cada nome que consultas antes de que exista calquera conexión. Se o teu dispositivo usa un resolutor público por HTTPS, o provedor ve unha conexión a ese resolutor e nada máis, mentres que o resolutor mesmo ve a lista.
Unha solicitude HTTP sen cifrar é lexible para o operador polo mesmo motivo polo que é lexible para a rede do hotel: nada no seu interior está cifrado. Un túnel nunca afirmou o contrario, e non arranxa a elección da aplicación.
Separa «isto é unha VPN» de «este son eu»
A detección é barata, probabilística e a miúdo errónea. Os enderezos de saída compartidos márcanse porque alguén máis abusou deles, os rangos corporativos clasifícanse como aloxamento, e os operadores móbiles producen resultados xeográficos que sorprenden a todos. A identificación é un problema distinto: necesita un vínculo persistente como unha conta coa que iniciaste sesión, unha cookie, un dato de pagamento ou dous observadores que comparan notas.
Decide contra cal dos dous loitas realmente. Se o obxectivo é ler unha páxina, HTTPS xa fai ese traballo e o túnel cambia pouco. Se o obxectivo é evitar que o sitio saiba en que cidade estás, a saída e o resolutor son o que importa. Se o obxectivo é romper o vínculo coa túa identidade real, a conta é o punto feble, e cambiar de servidor non fai nada polo inicio de sesión que acabas de usar.
Unha saída nova non te desconecta de nada, e non pode borrar o que un sitio xa gardou sobre a conta que usaches. A secuencia práctica é, pois, pouco espectacular: escolle unha saída cuxa rede pareza normal, mantén o perfil do navegador coherente con ela, actualiza o navegador para que as funcións propensas a fugas usen os seus valores predeterminados modernos, e acepta que un pequeno número de sitios seguirá equivocándose contigo.