Tu servidor ve la salida de la VPN, no al visitante

Un visitante se conecta mediante una VPN comercial y tu aplicación registra la dirección de salida. Eso no es una identidad oculta: es la única dirección de origen que tiene la conexión TCP. Todo lo demás que la gente llama detección es una inferencia superpuesta a ese único hecho.

Qué lleva realmente una petición

La aplicación ve la dirección y el puerto de origen de la conexión, el saludo que completó y los bytes que el cliente eligió enviar. Con un túnel completo, ese origen es la salida, compartida por todos los que la usan. Con un túnel dividido, las peticiones pueden llegar del túnel o de la conexión local según el destino. Si el cliente y el servidor están dentro de la misma VPN, el origen es la dirección interna del túnel del cliente, que identifica un extremo y no una ubicación.

Ningún campo de una petición ordinaria lleva la dirección que el cliente tenía antes del túnel. Una cabecera de reenvío es una afirmación del cliente o de un proxy, y puede omitirse o falsificarse.

La detección es clasificación, y la clasificación es una conjetura

Los métodos prácticos son listas de rangos conocidos de VPN y de alojamiento, latencia que no concuerda con una región declarada, formas de traceroute y comportamiento de la cuenta. Cada uno produce una probabilidad. Una VPN corporativa puede estar en direcciones que parecen residenciales, un proxy residencial puede parecer una línea doméstica, y el NAT del operador puede parecer un rango de alojamiento.

Bloquear una salida compartida bloquea a todos los usuarios no relacionados que hay detrás, lo que convierte una decisión de detección en una caída colateral. Una puntuación de confianza no es una identidad y nunca debería ser la única entrada de una decisión de bloqueo o de reembolso.

Si la VPN es tuya, tienes una señal fiable que no tiene nada que ver con la detección: asigna un grupo dedicado y compara el origen observado con él. Funciona porque controlas ambos extremos y puedes documentar el grupo. Pero no se generaliza a visitantes que no gestionas, y deja de ser fiable en el momento en que el grupo se comparte con otros servicios.

Pruebas locales frente a pruebas del lado del servidor

En la propia máquina un túnel es visible: un adaptador virtual, una ruta predeterminada que apunta a un dispositivo de túnel, un resolutor que cambió. El código que se ejecuta allí puede enumerar interfaces y buscar PPP, TAP o un controlador de proveedor.

Una página web no puede leer nada de eso. El rodeo habitual carga un recurso servido solo desde la red interna y trata el éxito como prueba de uso del túnel. En realidad prueba la accesibilidad: un túnel dividido, un archivo en caché obsoleto o un proxy de interceptación dan el mismo resultado en ambos estados. Las pruebas locales se quedan locales.

Elige controles de acceso que sobrevivan a la ambigüedad

Construye el control de acceso sobre identidad verificada, salud del dispositivo y autorización por recurso. Esos predicados describen quién pregunta y a qué puede llegar, y siguen teniendo sentido haya o no un túnel. Si una petición llegó por una VPN es una señal débil que produce tanto aceptaciones falsas como bloqueos colaterales. Mantén la prueba y la decisión en campos separados, para que un bloqueo discutido tenga algo que revisar.

La geolocalización por IP es una entrada entre varias, y los servicios de ubicación del navegador pueden usar Wi-Fi o GPS que nunca siguen el túnel. Un mapa que todavía muestra la ciudad del visitante es una prueba sobre los servicios de ubicación, no una prueba de que el túnel fallara.

Anota qué señal guió cada decisión. Cuando un cliente discute un bloqueo, ese registro es la diferencia entre una revisión y una discusión.