¿El tráfico pasa realmente por la VPN? Cómo verificarlo
La consulta de ruta, el primer salto, una captura en el adaptador físico y una comprobación de la dirección desde fuera responden a partes distintas de la pregunta.
Dos fallos se ven idénticos desde el icono de la bandeja: el tráfico que entra en el túnel y el tráfico que lo rodea en silencio. El cliente muestra Connected en ambos casos, porque Connected solo significa que la interfaz del túnel existe y que el cliente instaló las rutas que quería. Si un paquete de una aplicación usó esas rutas es una pregunta aparte, que se responde en otro punto de la pila. Cuatro mediciones resuelven la mayor parte — la consulta de ruta, el primer salto, una captura en el adaptador físico y una observación desde fuera — y la vista de sesión del servidor cubre el resto.
Empiece por la ruta que tomará el paquete
La tabla de enrutamiento es la decisión, así que pregúntele por un destino en lugar de leerla entera y adivinar. En Linux, ip route get nombra la interfaz y la dirección de origen que eligió el núcleo:
ip route get 203.0.113.10
ip route get 10.20.5.7En Windows, Find-NetRoute -RemoteIPAddress 203.0.113.10 es más útil que route print -4 por la misma razón: informa de la ruta que ganó, no de todas las rutas que existen. Aun así, lea la tabla una vez por su fila 0.0.0.0. Un par /1 allí significa que un cliente de túnel completo reescribió la ruta predeterminada: la opción redirect-gateway def1 de OpenVPN instala 0.0.0.0/1 y 128.0.0.0/1 por el túnel, lo que gana a la 0.0.0.0/0 existente por la coincidencia de prefijo más larga sin borrar la ruta predeterminada física. Por eso dos rutas predeterminadas pueden coexistir mientras todo sigue entrando en el túnel.
Dos detalles hacen que la tabla mienta. Primero, mire el prefijo que coincidió y no el número de rutas predeterminadas, porque la métrica de la interfaz o un par /1 deciden el ganador. Segundo, una conexión que ya existe conserva el camino con el que se estableció; tras levantar el túnel, una sesión abierta puede seguir usando la ruta antigua hasta que se reinicie, y por eso reconectar parece arreglar un problema de enrutamiento. Un cliente en ejecución — ps ax | grep openvpn — solo demuestra que el proceso arrancó.
Rastree un nombre interno y uno público
La consulta de ruta muestra la intención; el camino muestra la entrega. Rastree un nombre que debe ser interno y uno que no debe serlo, mientras está conectado, y compare el primer salto:
traceroute intranet.corp.example
traceroute 1.1.1.1El mismo primer salto para ambos significa que el nombre interno nunca entró en el túnel y que el fallo está por encima, normalmente un nombre que resuelve a una dirección pública o una ruta que nunca se instaló. Si el tráfico interno sale por 10.8.0.1 mientras el público sale por 192.168.1.1, el túnel dividido hace exactamente aquello para lo que se configuró. Un trazado que llega a la puerta de enlace de la VPN y luego solo devuelve tiempos de espera suele ser un problema de camino de vuelta o del cortafuegos del servidor, no una ruta de reenvío ausente.
El ICMP filtrado hace que esta comprobación mienta: estrellas en ambos trazados parecen un túnel muerto y normalmente son un cortafuegos. Pruebe un puerto TCP donde pueda — traceroute -T -p 443 en Linux — y recuerde que el trazado no dice qué resolutor respondió: un nombre puede resolverse localmente y seguir siendo alcanzable por el túnel.
Capture en el adaptador físico, no en el túnel
El enlace físico es el único lugar que muestra qué ve realmente la red. Con el túnel levantado, una sesión a la oficina debería aparecer como carga cifrada dirigida al servidor VPN, no como una conexión a 10.20.5.7:
sudo tcpdump -ni eth0 udp port 53
sudo tcpdump -ni eth0 host 10.20.0.5El primer filtro captura la resolución de nombres que sale localmente, que es la fuga más común y la más silenciosa — la página sigue cargando, el resolutor solo vio la consulta. El segundo captura tráfico plano hacia una dirección interna que solo debería existir dentro del túnel. En Windows, pktmon hace el mismo trabajo sin controlador: pktmon filter add -p 53, luego pktmon start --capture --pkt-size 128, luego pktmon stop y pktmon format pktmon.etl -o capture.txt. Esas opciones varían un poco entre compilaciones de Windows, así que compruebe pktmon filter add /? antes de fiarse de la sintaxis.
Capture la interfaz física para encontrar fugas; una captura en el túnel contiene los paquetes que ya cree que están ahí, y en un servidor contiene paquetes externos ilegibles cuya origen es la puerta de enlace. Los contadores de bytes de cualquier interfaz describen paquetes, no programas; atribuir tráfico a un proceso requiere un monitor que asocie sockets con procesos.
Pregunte a un servicio externo y vuelva a preguntar por aplicación
La única comprobación que demuestra la salida es una respuesta desde fuera: un servicio que devuelve la dirección de origen que vio. Ejecútelo desde un intérprete de órdenes, donde puede elegir la interfaz, y ejecútelo dos veces:
sudo curl --interface tun0 https://example.net/ip
sudo curl --interface eth0 https://example.net/ipRespuestas distintas le dan prueba de ambos caminos y una forma de probar una aplicación concreta: vincúlela, o ejecútela en un espacio de nombres de red con una sola ruta, y vea qué dirección registra el extremo remoto. Respuestas idénticas son el fallo interesante: o la vinculación no surtió efecto, o algo entre el host y el extremo remoto reescribe la dirección de origen antes de que llegue. En Windows, curl --interface quiere la dirección del adaptador y no su nombre.
Un navegador que informa de la dirección de la VPN demuestra el navegador. Un cliente de correo, un gestor de paquetes, un agente de copias de seguridad o un segundo perfil de navegador pueden tomar cada uno un camino distinto, sobre todo cuando un ajuste de proxy o una ruta de túnel dividido cubre uno de ellos. Un cambio de dirección no es prueba de fuga por sí mismo: un balanceador puede responder distinto según la salida que vio, así que compare la dirección de origen registrada, no la página.
Use la vista del servidor para confirmar el par
El servidor responde a otra pregunta: si un par está conectado, cuánto ha transportado y si la sesión se reinició. Un par activo en el servidor mientras los contadores del cliente apenas se mueven significa que el tráfico de la aplicación no entra en el túnel, diga lo que diga la tabla del cliente. Un par que mueve muchos datos para un usuario que informa de que nada funciona es otra investigación.
Aquí hay dos trampas. Un túnel enmascarado hace que cada flujo parezca venir de la puerta de enlace, así que los registros y la contabilidad por cliente se colapsan en una sola dirección. Y el cliente se trata como un host local, así que la pregunta sobre si alguien copia archivos por la VPN se responde con el tráfico de compartición de archivos en el servidor o con la auditoría del host en el servidor — vigilar el túnel da extremos y volumen, no nombres de archivo.
Distinga una decisión de diseño de una fuga
No todo lo que queda fuera del túnel es una fuga. El tráfico de enlace local y de difusión se queda local por diseño, una impresora descubierta por multicast sigue anunciándose en la LAN, y DHCP tiene que salir localmente. Una aplicación vinculada a una interfaz concreta evade la tabla de enrutamiento a propósito, y solo una regla de cortafuegos, un espacio de nombres o una ruta de política lo cambian.
IPv6 merece su propia línea en la lista de comprobación. Un túnel que solo transporta IPv4 deja a un host de doble pila con un segundo camino utilizable, y un destino de doble pila lo preferirá — incluido DNS, si el resolutor es alcanzable por IPv6. Desactive IPv6 en el adaptador o confirme que el túnel lo transporta antes de dar por completo un resultado IPv4.
Cuando las comprobaciones no coinciden, la discrepancia suele señalar el fallo:
| What you see | What it means | Next step |
|---|---|---|
| The route picks tun0 but the capture shows cleartext to 10.20.5.7 | Something bypassed the table: a bound app, a policy route or a session older than the tunnel | Reset the flow, check the app bind, check the ip rule list |
| The route picks eth0 for an internal name | The name resolves to a public address, or the route was never installed | Compare the resolved address with the routes the server pushes |
| The capture shows DNS to the LAN resolver | Resolver leak: data is tunneled, lookups are not | Point the resolver inside, or push it from the server |
| All four checks agree and one app still fails | Path selection is fine; suspect MTU, a per-app proxy or the far end | Test the same destination from a known-good client |
Un orden que funciona: guarde la tabla de enrutamiento antes y después de conectar, rastree un nombre interno y uno público, capture DNS en el adaptador físico, devuelva la dirección de salida desde el intérprete para la aplicación concreta y luego lea el servidor por volumen. Si las cuatro primeras coinciden, el túnel transporta lo que usted cree y el problema restante está por encima. Si dos de ellas no coinciden, el par que discrepa es el fallo, no el icono.