Cómo registrar y verificar la dirección de salida VPN que usó

Pregunte a un cliente VPN de escritorio qué servidores ha usado y la respuesta honesta suele ser un nombre de ubicación. Ese nombre es el punto de entrada que marcó, y la dirección por la que salió su tráfico puede ser una máquina completamente distinta. Nada en la app está diseñado para conservar el segundo número, así que el registro debe construirse en el momento del uso. Existen dos enfoques, y solo uno de ellos sobrevive a un caso de soporte.

Dos registros, y solo uno de ellos existe

La vista del propio cliente es, en el mejor de los casos, una lista de ubicaciones elegidas con marcas de tiempo. Es una decisión de diseño y no un descuido: las direcciones son detalle operativo, rotan entre asignaciones, y exponer la correspondencia dificulta tanto el soporte como la gestión de abusos. Los proveedores ponen instancias en la nube delante de sus redes precisamente para que el extremo pueda moverse sin avisar a nadie. Lo que la app le muestra es la elección que hizo, no la ruta que tomó.

El registro que usted puede construir es un archivo local con una dirección pública y una marca de tiempo UTC por línea. Es más pequeño, más feo y mucho más útil, porque describe exactamente lo que un observador externo también puede ver.

Opción A: capture usted mismo la dirección de salida

Un servicio de eco devuelve la dirección de origen desde la que llegó la solicitud, que es la dirección de salida por definición. Ejecute la captura después de que el túnel informe conectado, porque un cliente que dice conectado antes de que las rutas y el DNS se asienten registrará la dirección previa al túnel y envenenará el registro desde su primera línea.

#!/bin/sh
umask 077
log="$HOME/vpn-exit.log"
printf '%s %s\n' "$(date -u +%Y-%m-%dT%H:%M:%SZ)" "$(curl -fsS https://api.ipify.org)" >> "$log"

Dos detalles hacen que ese fragmento sea utilizable y no decorativo. La marca de tiempo y la dirección comparten una línea, de modo que un análisis posterior no tiene que emparejar registros, y umask 077 mantiene el archivo privado desde el momento en que se crea. Ejecútelo una vez por conexión en lugar de una vez por arranque, y mantenga un archivo por dispositivo.

El registro anota cuándo usó un túnel y desde qué red apareció, lo que está más cerca de un historial de navegación que de un contador. Elija un periodo de retención que pueda defender, mantenga el archivo fuera de carpetas de sincronización compartidas y purgue a propósito.

Opción B: pida un historial al proveedor

Algunos proveedores guardan registros de conexión y responderán a una pregunta de soporte con una marca de tiempo y un nombre de servidor. Ese registro describe su infraestructura y no su tráfico, y solo vale lo que valen su ventana de retención y su disposición a mirar. Además describe una sesión, no una solicitud. La ventana suele ser corta, y se mide desde el lado del proveedor del túnel.

Los proveedores que anuncian que no registran no pueden producir esto a petición, y una lista de ubicaciones recientes del lado del cliente no es lo mismo. Pedir una dirección de salida a un proveedor sin registros suele terminar con una explicación de por qué esos datos no existen.

Qué puede probar cada registro en un caso de soporte

Los dos registros responden preguntas distintas, y es en la tabla donde la comparación deja de ser académica.

Solo la primera columna está bajo su control. Un registro del proveedor puede confirmar que una cuenta estuvo conectada en un momento dado, pero no puede confirmar qué solicitudes usaron el túnel, y no nombrará una dirección que el proveedor trata como detalle operativo. Ninguno de los dos registros identifica a una persona, porque una dirección de salida compartida puede llevar a muchos clientes en el mismo minuto.

Compare ambos con una referencia antes de fiarse de cualquiera

Una dirección por sí sola no prueba nada. Capture la dirección directa antes de conectar, la dirección tunelizada después, y compárelas. Valores idénticos significan que el túnel no transporta esa solicitud, ya sea por un túnel dividido, un proxy preponderante o un cliente que cayó a una ruta directa.

curl -fsS https://api.ipify.org; echo
curl -fsS https://api64.ipify.org; echo
dig +short TXT o-o.myaddr.l.google.com @1.1.1.1

Repita la comparación para DNS y para IPv6, porque un eco de dirección prueba la ruta de una sola solicitud HTTP y nada sobre qué resolutor respondió. Un dispositivo que filtra en uno de los dos puede verse perfectamente sano en el otro.