O teu servidor ve a saída da VPN, non o visitante

Un visitante conéctase mediante unha VPN comercial e a túa aplicación rexistra o enderezo de saída. Iso non é unha identidade oculta: é o único enderezo de orixe que ten a conexión TCP. Todo o demais que a xente chama detección é unha inferencia sobreposta a ese único feito.

Que leva realmente unha petición

A aplicación ve o enderezo e o porto de orixe da conexión, o saúdo que completou e os bytes que o cliente escolleu enviar. Cun túnel completo, esa orixe é a saída, compartida por todos os que a usan. Cun túnel dividido, as peticións poden chegar do túnel ou da conexión local segundo o destino. Se o cliente e o servidor están dentro da mesma VPN, a orixe é o enderezo interno do túnel do cliente, que identifica un extremo e non unha localización.

Ningún campo dunha petición ordinaria leva o enderezo que o cliente tiña antes do túnel. Unha cabeceira de reenvío é unha afirmación do cliente ou dun proxy, e pode omitirse ou falsificarse.

A detección é clasificación, e a clasificación é unha conxectura

Os métodos prácticos son listas de rangos coñecidos de VPN e de aloxamento, latencia que non concorda cunha rexión declarada, formas de traceroute e comportamento da conta. Cada un produce unha probabilidade. Unha VPN corporativa pode estar en enderezos que parecen residenciais, un proxy residencial pode parecer unha liña doméstica, e o NAT do operador pode parecer un rango de aloxamento.

Bloquear unha saída compartida bloquea todos os usuarios non relacionados que hai detrás, o que converte unha decisión de detección nunha caída colateral. Unha puntuación de confianza non é unha identidade e nunca debería ser a única entrada dunha decisión de bloqueo ou de reembolso.

Se a VPN é túa, tes un sinal fiable que non ten nada que ver coa detección: asigna un grupo dedicado e compara a orixe observada con el. Funciona porque controlas ambos os extremos e podes documentar o grupo. Pero non se xeneraliza a visitantes que non xestionas, e deixa de ser fiable no momento en que o grupo se comparte con outros servizos.

Probas locais fronte a probas do lado do servidor

Na propia máquina un túnel é visible: un adaptador virtual, unha ruta predeterminada que apunta a un dispositivo de túnel, un resolutor que cambiou. O código que se executa alí pode enumerar interfaces e buscar PPP, TAP ou un controlador de provedor.

Unha páxina web non pode ler nada diso. O rodeo habitual carga un recurso servido só desde a rede interna e trata o éxito como proba de uso do túnel. En realidade proba a accesibilidade: un túnel dividido, un ficheiro na caché obsoleto ou un proxy de interceptación dan o mesmo resultado en ambos os estados. As probas locais quedan locais.

Escolle controis de acceso que sobrevivan á ambigüidade

Constrúe o control de acceso sobre identidade verificada, saúde do dispositivo e autorización por recurso. Eses predicados describen quen pregunta e a que pode chegar, e seguen tendo sentido haxa ou non un túnel. Se unha petición chegou por unha VPN é un sinal feble que produce tanto aceptacións falsas como bloqueos colaterais. Mantén a proba e a decisión en campos separados, para que un bloqueo discutido teña algo que revisar.

A xeolocalización por IP é unha entrada entre varias, e os servizos de localización do navegador poden usar Wi-Fi ou GPS que nunca seguen o túnel. Un mapa que aínda mostra a cidade do visitante é unha proba sobre os servizos de localización, non unha proba de que o túnel fallase.

Anota que sinal guiou cada decisión. Cando un cliente discute un bloqueo, ese rexistro é a diferenza entre unha revisión e unha discusión.