Qué puede y qué no puede ver un firewall corporativo dentro de una VPN

El mismo portátil llega a la VPN desde casa y no puede conectarse desde la oficina, así que alguien debe de estar leyendo el tráfico. Bloquear y leer son poderes separados, y solo el segundo necesita un punto en el camino más un certificado en el que el cliente confíe. Un elemento intermedio que descarta tu handshake no ha aprendido nada sobre lo que habrías enviado. Decidir cuál de los dos tienes delante es todo el trabajo.

Bloquear y leer son poderes distintos

Un rechazo es barato y ruidoso: el socket se abre y nada responde, o llega un reset de inmediato. Nada de eso implica inspección, porque ninguna carga cruzó el cable.

Leer requiere un punto final que termine la protección, se acredite con un certificado y abra una conexión nueva hacia delante. Ese punto debe estar en el camino y ser de confianza para el cliente. Un firewall que solo reenvía paquetes no tiene ni posición ni credencial.

Qué regala la envoltura

Cada paquete del túnel tiene un exterior, y el exterior debe ser enrutable. Eso significa dos direcciones, un protocolo, un puerto y una longitud, además de tiempos y volumen. Cualquier router ya maneja esos campos, y un NAT reescribe la dirección y el puerto para mantener coherente su tabla de mapeo. La carga sigue sellada, así que la observación se detiene en el hecho de que existe un túnel entre dos hosts.

Un nombre de host no está entre ellos. Los sitios se filtran por otras puertas, y la más ancha es DNS: si el portátil sigue preguntando al resolutor local, los nombres aparecen en claro.

Los tiempos y el volumen merecen respeto sin exagerarlos. Bytes por minuto pueden mostrar que una transferencia grande empieza a las 14:20; no pueden mostrar qué archivo se movió. Es una revelación real sobre el comportamiento, y una categoría distinta de leer contenido.

La interceptación TLS necesita una raíz en la que ya confíes

Un dispositivo de inspección no rompe TLS; lo termina. Al cliente le responde un certificado de una raíz que posee la organización, y una segunda conexión va al destino real. El cliente lo acepta porque esa raíz está en su almacén de confianza, y por eso un portátil gestionado no muestra ningún aviso. La criptografía nunca fue derrotada; se movió el punto final.

También por eso el montaje deja pruebas. El emisor de la cadena presentada pertenece a la organización y no a una CA pública, y un cliente puede verlo sin herramientas especiales. Una cadena que acaba en una raíz interna es la firma de la interceptación, no una avería.

Por qué un canal VPN no es una sesión HTTPS

Un canal de datos VPN no da al inspector ese punto de apoyo. IKEv2 y WireGuard ejecutan sus propios handshakes y calendarios de claves, sin TLS que terminar, mientras que OpenVPN toma prestado TLS para su canal de control en una forma modificada antes de proteger los datos a su manera. Un proxy hecho para HTTPS no reconoce esa sesión como algo que pueda analizar.

Un dispositivo que no puede analizar una sesión aún puede descartarla. Por eso el bloqueo de VPN suele parecer un tiempo de espera y no un aviso de certificado, y por eso una excepción no cambia nada.

Comprobarlo desde tu propia máquina

Empieza por la cadena que presenta el sitio. Los detalles del sitio en el navegador muestran el emisor, y la línea de comandos informa de lo mismo sin el resumen:

openssl s_client -connect example.com:443 -servername example.com

Luego separa un handshake rechazado del tráfico interno filtrado con contadores. Registra el puerto de transporte antes de cualquier regla de descarte y léelos después del intento:

iptables -I OUTPUT 1 -p udp --dport 1194 -j LOG --log-prefix ovpn-out
iptables -vnL OUTPUT --line-numbers

Ninguna línea de registro en el socket exterior significa que el handshake nunca salió, así que el camino rechaza el túnel. Un handshake completado con solo algunos destinos fallando significa que el túnel funciona y la política interior no. Ninguno de los dos resultados exigió leer un byte de carga.

La lectura que sí ocurre está en los bordes: un túnel dividido entrega el HTTPS interno a un proxy corporativo, y un concentrador propiedad de la empresa lo expone todo en la salida. Encuentres lo que encuentres, no desactives la verificación de certificados para forzar una conexión, porque esa comprobación es lo único que separa la inspección de un atacante.