O site bloqueia você só com a VPN ligada? Isto é o que ele vê
O bloqueio costuma ser o endereço de saída, não um vazamento. Verifique a rede de onde seu tráfego parece vir, o resolvedor que um site pode registrar e o que o código da página sabe.
A loja carrega bem em casa e mostra uma parede de «tráfego incomum» no momento em que o túnel sobe. Um fórum se recusa a fazer login, e uma página de streaming insiste que você está em um país que nunca visitou. Nada disso exige software espião. Um site vê o endereço de onde chegam seus pacotes, e com uma VPN esse endereço pertence a um data center em vez de uma linha doméstica. A maior parte do que se chama detecção de VPN começa e termina nesse único fato, e o resto é inferência com uma taxa de erro previsível.
O bloqueio começa por onde parece que seus pacotes vêm
Cada solicitação carrega um endereço de origem, e o servidor que a recebe pode consultá-lo em dados públicos: qual rede o anuncia, se essa rede é um provedor de hospedagem, se apareceu em listas de abuso e qual país o registro atribui. Nada disso identifica você, e tudo junto basta para encaixotá-lo.
Olhe para o seu próprio tráfego como um estranho faria. Dois comandos cobrem a maior parte da superfície, e o segundo é o que as pessoas esquecem:
curl -sS https://ipinfo.io/json
dig +short TXT o-o.myaddr.l.google.com @ns1.google.com
O primeiro devolve o endereço de saída, sua organização e seu país. O segundo devolve o endereço do resolvedor que chegou ao servidor de nomes do Google, que muitas vezes está em uma rede diferente da sua saída e é o endereço que um site vê se registra dados do lado do resolvedor. Quando esses dois pertencem a países diferentes, alguns sites tratam a discrepância como suspeita mesmo que não haja nada errado na sua configuração.
Quando a recusa começa só depois que o túnel sobe, suspeite do endereço de saída antes de qualquer outra coisa. Troque de servidor e tente de novo antes de tocar no navegador. Um bloqueio que o segue por três saídas do mesmo provedor tem a ver com as faixas do provedor; um bloqueio que desaparece em outro servidor tem a ver com aquele único endereço.
Fuso horário, idioma e relógio não batem com o endereço
O código da página pode ler seu fuso horário, suas preferências de idioma e as configurações de tela sem qualquer pedido de permissão. Um navegador que informa horário da Europa Central enquanto a conexão vem de um data center em Singapura é um sinal mais forte do que o endereço sozinho, e é exatamente o tipo de discrepância que a pontuação antifraude foi feita para notar.
Intl.DateTimeFormat().resolvedOptions().timeZone
navigator.language
Intl.DateTimeFormat().resolvedOptions().locale
Essas três linhas no console do desenvolvedor dizem o que seu navegador entrega voluntariamente. Um cliente VPN pode mudar sua rota e nada mais, então o perfil que você carrega continua doméstico enquanto sua saída não é. A consistência é o que importa aqui: um notebook configurado na mesma região da saída parece normal, e um que se contradiz não.
É também por isso que a falha é intermitente. Muitos sites não se importam, alguns poucos pontuam, e um site de assinatura decide que você é um fraudador. O cliente funciona corretamente nos três casos, e por isso a resposta habitual do suporte, «deve ser o seu navegador», é ao mesmo tempo irritante e em parte verdadeira.
O que o código da página realmente sabe sobre a sua máquina
JavaScript não tem API que enumere interfaces de rede. Uma página não pode perguntar quais endereços o seu notebook tem, então a velha afirmação de que um script lê o seu endereço LAN é sobretudo uma memória da era dos plugins, quando controles ActiveX, applets Java e outro código nativo podiam fazer exatamente isso.
| 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 exceção honesta a «nenhum vazamento de endereço local». A coleta de candidatos dele expunha antes endereços locais a qualquer página que pedisse, e a correção foi substituir candidatos de host por nomes mDNS aleatórios. Esse padrão vale nos navegadores atuais, mas é uma decisão do navegador e não uma garantia do protocolo, então uma versão desatualizada ou uma configuração endurecida que reative candidatos locais ainda pode vazar. Atualizar o navegador ajuda você aqui mais do que qualquer extensão.
Seu provedor vê os nomes, não os conteúdos
O HTTPS protege o conteúdo de uma página de ponta a ponta, e o operador do túnel que encaminha esses bytes não consegue lê-los. O operador ainda pode ver a qual endereço você se conectou, e na maioria das implantações o nome do servidor no handshake, porque o nome precisa ser legível para que a conexão seja encaminhada ao site certo. Encrypted Client Hello existe justamente para esconder esse campo, e só ajuda quando tanto o cliente quanto o site o suportam.
A resolução de nomes é a outra metade. Se o seu provedor também fornece o resolvedor, ele vê cada nome que você consulta antes de existir qualquer conexão. Se o seu dispositivo usa um resolvedor público por HTTPS, o provedor vê uma conexão com esse resolvedor e nada mais, enquanto o próprio resolvedor vê a lista.
Uma solicitação HTTP não criptografada é legível para o operador pelo mesmo motivo que é legível para a rede do hotel: nada dentro dela está criptografado. Um túnel nunca afirmou o contrário, e não conserta a escolha do aplicativo.
Separe «isto é uma VPN» de «este sou eu»
A detecção é barata, probabilística e frequentemente errada. Endereços de saída compartilhados são marcados porque outra pessoa abusou deles, faixas corporativas são classificadas como hospedagem, e operadoras móveis produzem resultados geográficos que surpreendem todo mundo. A identificação é outro problema: exige um vínculo persistente como uma conta em que você entrou, um cookie, um dado de pagamento ou dois observadores comparando anotações.
Decida contra qual dos dois você realmente luta. Se o objetivo é ler uma página, o HTTPS já faz esse trabalho e o túnel muda pouco. Se o objetivo é impedir que o site saiba em que cidade você está, a saída e o resolvedor são o que importa. Se o objetivo é romper o vínculo com sua identidade real, a conta é o ponto fraco, e trocar de servidor não faz nada pelo login que você acabou de usar.
Uma saída nova não desconecta você de nada, e não pode apagar o que um site já guardou sobre a conta que você usou. A sequência prática é, portanto, sem glamour: escolha uma saída cuja rede pareça normal, mantenha o perfil do navegador coerente com ela, atualize o navegador para que os recursos propensos a vazamentos usem seus padrões modernos, e aceite que um pequeno número de sites ainda vai errar sobre você.