Dónde observar el tráfico de un cliente OpenVPN en la pasarela

Quiere saber a qué destinos llega un cliente conectado, así que abre un intérprete de órdenes en el servidor VPN y escribe ss. No aparece nada útil, y la conclusión de que el túnel está roto llega con demasiada facilidad. Una pasarela OpenVPN enrutada reenvía los paquetes del cliente; no termina sus conexiones TCP ni posee sockets para ellas. La prueba vive en otro lugar, y cuál depende de cómo se trate el tráfico una vez que sale del túnel.

Decida qué disposición está mirando

Dos formas habituales producen pruebas completamente distintas. Una pasarela de enrutamiento desencapsula, reenvía y quizá aplica NAT de origen, de modo que la conexión del cliente sigue existiendo de extremo a extremo sin un socket local.

Un proxy termina el tráfico: acepta la conexión y luego abre su propia conexión ascendente. En esa disposición hay dos conexiones para una petición, y la asociación entre ellas solo existe en los registros propios del proxy. Saber cuál de las dos ha desplegado decide si debe leer el estado de flujos del núcleo o los registros de la aplicación.

La mayor parte de la confusión viene de adivinar. Confirme la forma antes de elegir la herramienta. Lea primero la configuración del servidor en busca de una directiva de proxy, porque su presencia cambia todos los pasos posteriores. Sin ella, la ruta de los paquetes es enrutamiento y el estado de flujos del núcleo es su prueba.

Ate primero la dirección a una sesión

Empiece por el estado de sesiones del servidor e identifique la dirección interna actual del cliente. Las direcciones del grupo se reciclan, así que una dirección por sí sola es un alquiler, no una persona.

Anote la hora y la identidad autenticada juntas, y fíjese en si toda una LAN se esconde detrás de ese cliente. Si el extremo remoto enruta una subred, las direcciones internas que ve puede que sean equipos originales o traducidos.

ip -4 addr show dev tun0
journalctl -u [email protected] --since '-10 min' | tail -n 40

Ese par responde dos preguntas a la vez: qué prefijo sirve la interfaz del túnel y qué sesión estaba activa durante el intervalo que le interesa. Hágalo antes de interpretar cualquier entrada de flujo, porque una tupla convincente atada a la sesión equivocada es peor que no tener ninguna prueba.

Lea la tabla de flujos en una pasarela de enrutamiento

Establecidas la dirección y el intervalo, un listado de solo lectura de las conexiones rastreadas muestra qué reenvía la pasarela para ella. Filtre por el origen original para no leer toda la tabla.

sudo conntrack -L -p tcp -f ipv4 --orig-src 10.8.0.37

Cada entrada contiene dos tuplas, original y respuesta, que son las dos direcciones de un mismo flujo y no dos aplicaciones. En una ruta con NAT de origen la tupla original conserva la dirección del túnel mientras el lado de respuesta muestra la dirección traducida de la pasarela, y eso es exactamente lo que hace que la salida parezca incorrecta a primera vista.

Trate el listado como estado vivo y no como historial. Los flujos cortos pueden haber caducado ya, el tráfico no rastreado nunca aparece, y otro espacio de nombres de red muestra otra tabla. La referencia de conntrack documenta los filtros y la salida en dos direcciones.

Una captura acotada para confirmar la lectura

Si la interfaz del túnel es visible donde mira, una sola captura acotada resuelve si los paquetes que identificó son los que hay en el cable. Mantenga el filtro estrecho y el límite de paquetes pequeño.

sudo tcpdump -ni tun0 -nn -c 50 'host 10.8.0.37 and tcp'

Compare marcas de tiempo, protocolo y puertos con la entrada de flujo y con la petición que hizo como prueba. Una captura tomada después del NAT solo muestra la dirección pública de la pasarela, mientras que el lado del túnel aún puede mostrar la del cliente, y esa diferencia es información y no una inconsistencia.

Si la interfaz no ve nada, compruebe la ruta de datos antes de concluir que el cliente está inactivo: el tráfico de cliente a cliente y algunas rutas de descarga nunca atraviesan el punto que vigila.

Registros del proxy y los límites de lo que vio

Cuando un proxy está en la ruta, sus sockets ascendentes son visibles en la tabla de sockets pero no se corresponden uno a uno con los clientes VPN, sobre todo con agrupación o multiplexación. Use el registro de transacciones configurado del proxy para correlacionar la identidad del cliente, el destino, la marca de tiempo y cualquier identificador de petición que registre.

Revise la configuración de registro de la versión desplegada en lugar de suponer que toda petición se registra por defecto.

Por último, sea preciso sobre el alcance. Una dirección de destino y un puerto son metadatos, no una URL ni el contenido de una página, porque la sesión HTTPS interna conserva su propia protección con independencia del túnel. Informe de lo que observó, desde qué punto de observación y a qué hora.