La IP de salida de una VPN no demuestra un túnel: qué ven los servidores

Alguien pide un servicio al que solo pueden llegar los usuarios de VPN, y la implementación obvia es permitir una lista de direcciones de salida. La lista hace algo real: restringe quién puede conectarse. No demuestra que se haya usado un túnel, porque la dirección pertenece a quien opera la salida y ese operador puede reenviar el tráfico de cualquiera. La brecha entre esas afirmaciones es todo el problema de diseño.

El servidor ve una dirección por conexión

Una conexión llega con una dirección de origen y un puerto de destino, y eso es todo lo que informa la capa de red. Cuando un cliente usa un túnel, los paquetes que llegan a su escucha vienen de la salida o de la traducción delante de ella. La dirección propia del cliente, normalmente privada, nunca aparece. Por eso, una regla de cortafuegos escrita para el rango de la LAN del cliente no hace absolutamente nada.

Todo lo que hay después de esa dirección de origen son datos de aplicación, y la aplicación solo puede confiar en ellos en la medida en que los autentica.

Compruebe cómo se ve su salida

Mire el camino desde ambos extremos antes de escribir una regla. La visión del cliente sobre su salida y la visión del servidor sobre la conexión son los dos hechos que importan.

curl -sS https://api.ipify.org; echo
ss -tn state established '( sport = :443 )' | head

El primer comando informa de la dirección pública con la que aparece el cliente, y ese es el valor que debe contener cualquier lista de permitidos. El segundo muestra las conexiones establecidas en el servidor con las direcciones de sus pares, y es con eso con lo que la regla coincidirá realmente. Si los dos no concuerdan con su modelo mental, corrija el modelo antes de editar la política. Un cortafuegos de base de datos en la nube, una lista de permitidos de aplicación y un balanceador de carga pueden ver cada uno una capa de traducción distinta.

Solo se puede listar uno de los dos conjuntos de salida

Un caso se puede comprobar en el momento de la petición y el otro no, lo que produce garantías muy distintas.

curl -sS https://check.torproject.org/torbulkexitlist | wc -l

La lista publicada de salidas de Tor se puede obtener y comparar, sujeta a la antigüedad de la lista y a la política propia de cada salida, así que una regla de denegación contra salidas conocidas es aplicable y revisable. No existe un registro equivalente para las VPN comerciales. Las direcciones rotan, muchos proveedores no publican nada, y un túnel puede funcionar en una dirección de nube alquilada que nunca perteneció a una VPN. La lista que usted compile es una instantánea de direcciones observadas, y ampliarla a rangos de alojamiento añade cargas no relacionadas sin añadir pruebas.

Use las direcciones como entrada de política, no como prueba

Decida para qué sirve la regla. Una restricción de red debe mantenerse estrecha, registrar la dirección observada con su fecha y su motivo, y dar a los usuarios legítimos una vía de recuperación cuando cambie su salida. El control de acceso necesita una cuenta autenticada o un token firmado, porque solo estos vinculan una petición a una identidad. La puntuación de riesgo puede usar la dirección como una única señal poco fiable, aceptando sus falsos positivos y sus puntos ciegos. Escribir la regla como decisión de producto es honesto; escribirla como verificación de que existe un túnel, no.

La petición espejo, recuperar la dirección real del usuario detrás de una VPN, falla por el mismo motivo: una conexión lleva una dirección, y un cambio entre sesiones es compatible con varias explicaciones. Trate el valor anterior como historia, no como verdad.