O seu servidor vê a saída da VPN, não o visitante

Um visitante liga-se através de uma VPN comercial e a sua aplicação registra o endereço de saída. Isso não é uma identidade oculta: é o único endereço de origem que a ligação TCP tem. Tudo o resto que as pessoas chamam detecção é uma inferência sobreposta a esse único facto.

O que um pedido realmente transporta

A aplicação vê o endereço e a porta de origem da ligação, o aperto de mão completo e os bytes que o cliente escolheu enviar. Num túnel completo, essa origem é a saída, partilhada por todos os que a usam. Num túnel dividido, os pedidos podem chegar do túnel ou da ligação local conforme o destino. Se o cliente e o servidor estiverem ambos dentro da mesma VPN, a origem é o endereço interno do túnel do cliente, que identifica um extremo e não uma localização.

Nenhum campo de um pedido comum transporta o endereço que o cliente tinha antes do túnel. Um cabeçalho de encaminhamento é uma afirmação do cliente ou de um proxy, e pode ser omitido ou falsificado.

A detecção é classificação, e a classificação é um palpite

Os métodos práticos são listas de intervalos conhecidos de VPN e de alojamento, latência que não concorda com uma região declarada, formas de traceroute e comportamento da conta. Cada um produz uma probabilidade. Uma VPN empresarial pode estar em endereços que parecem residenciais, um proxy residencial pode parecer uma linha doméstica, e o NAT do operador pode parecer um intervalo de alojamento.

Bloquear uma saída partilhada bloqueia todos os utilizadores não relacionados por trás dela, o que transforma uma decisão de detecção numa falha colateral. Uma pontuação de confiança não é uma identidade e nunca deve ser a única entrada de uma decisão de banimento ou de reembolso.

Se a VPN for sua, tem um sinal fiável que nada tem a ver com detecção: atribua um pool dedicado e compare a origem observada com ele. Funciona porque controla ambas as pontas e pode documentar o pool. Mas não se generaliza a visitantes que não gere, e deixa de ser fiável no momento em que o pool é partilhado com outros serviços.

Provas locais versus prova do lado do servidor

Na própria máquina um túnel é visível: um adaptador virtual, uma rota predefinida que aponta para um dispositivo de túnel, um resolver que mudou. Código a correr ali pode enumerar interfaces e procurar PPP, TAP ou um controlador do fornecedor.

Uma página web não consegue ler nada disso. O contorno habitual carrega um recurso servido apenas a partir da rede interna e trata o sucesso como prova de uso do túnel. Na verdade testa a acessibilidade: um túnel dividido, um ficheiro em cache desatualizado ou um proxy de intercepção dão o mesmo resultado em ambos os estados. As provas locais ficam locais.

Escolha controlos de acesso que sobrevivam à ambiguidade

Construa o controlo de acesso sobre identidade verificada, saúde do dispositivo e autorização por recurso. Esses predicados descrevem quem pergunta e a que pode chegar, e continuam a ser significativos haja ou não um túnel envolvido. Se um pedido chegou por uma VPN é um sinal fraco que produz tanto aceitações falsas como bloqueios colaterais. Mantenha a prova e a decisão em campos separados, para que um bloqueio contestado tenha algo a rever.

A geolocalização por IP é uma entrada entre várias, e os serviços de localização do navegador podem usar Wi-Fi ou GPS que nunca seguem o túnel. Um mapa que ainda mostra a cidade do visitante é uma prova sobre os serviços de localização, não uma prova de que o túnel falhou.

Anote que sinal guiou cada decisão. Quando um cliente contesta um bloqueio, esse registo é a diferença entre uma revisão e uma discussão.