¿El cortafuegos bloquea la VPN? Una comprobación paso a paso

Un solo tiempo de espera agotado de la VPN demuestra que no llegó ninguna respuesta utilizable, y no demuestra nada sobre el porqué. El perfil puede indicar el puerto equivocado, el servidor puede estar caído o la solicitud puede llegar sin una ruta de retorno funcional. Cada uno de esos casos deja una traza distinta, y la traza es lo que le dice qué regla tocar. Recorra las cuatro etapas siguientes en orden. Deténgase en cuanto una de ellas explique el síntoma.

Paso 1: confirme el servidor y el transporte

Lea el nombre del servidor, el transporte y el puerto del perfil actual del operador y no de una edición local. Un puerto cambiado en su portátil no puede crear un oyente en un servidor público, y esa discrepancia produce un tiempo de espera idéntico a un bloqueo. Si el perfil ofrece un transporte alternativo compatible, anótelo como respaldo y no como solución. Resuelva el nombre y compare la respuesta con la dirección que el operador publicó.

Un registro DNS obsoleto envía al cliente a un host que nunca respondió. Es otra falla que imita un filtro, y descartarla cuesta una sola consulta.

Escriba ambos valores en el tique. Todas las comparaciones posteriores los usan, y un tique sin ellos reinicia la investigación.

Paso 2: demuestre la ruta con una única comparación controlada

Mantenga el dispositivo y el perfil sin cambios y pruebe otra red de acceso de confianza. Si el túnel se levanta allí, la diferencia es la ruta original o su política. Si un segundo dispositivo aprobado funciona en la red original, la diferencia es el primer dispositivo. Una de esas dos comparaciones es casi siempre decisiva.

Complete primero cualquier inicio de sesión de red legítimo, porque un portal cautivo parece un bloqueo hasta que se completa.

Pruebe el puerto que realmente usa, y trate un resultado TCP como información solo sobre TCP.

Resolve-DnsName vpn.corp.example
tracert -h 8 -w 500 vpn.corp.example
Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed

Un handshake TCP correcto en el puerto 443 dice que allí respondió un oyente. No dice nada sobre un oyente UDP en el 51820 ni sobre si la negociación se completó.

Paso 3: lea los eventos de seguridad del momento de la falla

Los eventos del cortafuegos son la prueba más sólida disponible, y llevan una advertencia que conviene decir primero. El registro está desactivado en muchos perfiles predeterminados, así que compruebe si el perfil correspondiente registra descartes antes de leer un registro vacío como prueba de inocencia. Cuando el registro está activo, el evento indica la regla, la dirección y las direcciones, que es exactamente lo que necesita un cambio de regla. Las reglas de aplicación y las reglas de puerto son objetos separados, y la política gestionada puede anular un ajuste local. Confirme qué cliente y qué servicio cubre realmente una regla.

Recoja el estado del perfil y los eventos recientes de la máquina que falló, no de un host vecino.

Lea la hora del evento frente a la hora de su intento de prueba, porque un nombre de regla coincidente con una marca de tiempo distinta es una casualidad.

Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, LogBlocked
Get-NetFirewallRule -Enabled True -Direction Outbound | Where-Object DisplayName -match 'VPN'
Get-WinEvent -LogName 'Microsoft-Windows-Windows Firewall With Advanced Security/Firewall' -MaxEvents 20

En un servidor que administre, pregunte si la solicitud llegó siquiera al oyente. Un paquete que llega sin respuesta es un problema de reenvío o de ruta de retorno. Una solicitud que nunca aparece es un problema de filtrado o de direccionamiento.

Paso 4: pruebe el reenvío una vez levantado el túnel

Un cortafuegos puede permitir la sesión y aun así denegar todo lo que la sesión quiere alcanzar. Los sysctl de reenvío, las reglas NAT y las rutas de retorno están todos después de la autenticación, y una exención amplia para el puerto de la VPN no repara ninguno de ellos. Pruebe un destino interno y un destino de internet por separado, porque suelen fallar por motivos distintos. Si los nombres internos fallan pero las direcciones funcionan, mire el DNS empujado antes que cualquier regla.

Ejecute las tres comprobaciones siguientes en el servidor mientras un cliente está conectado e intenta la solicitud que falla.

Los contadores de la interfaz del túnel son el punto clave, porque muestran si entraron paquetes y si salió algo.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -n -E 'forward|masquerade'
tcpdump -ni tun0 -c 10

Cuando llegan paquetes al túnel y no sale nada hacia el destino, el sospechoso es el reenvío o el NAT. Cuando no llega nada, la sesión está levantada pero el cliente no envía, y el lugar donde mirar es la tabla de rutas del cliente.

Compruebe la corrección y elimine lo que no ayudó

Tras una corrección aprobada, repita exactamente la prueba que falló y registre el resultado con el mismo perfil y dispositivo. Después elimine cualquier excepción temporal que no cambiara el resultado, porque las excepciones sin usar se acumulan y cada una es una decisión que nadie recuerda haber tomado. Mantenga estrecho lo que quede: un destino, un puerto, una dirección, un responsable.

Vuelva a ejecutar los mismos tres comandos y compárelos con las salidas que guardó antes del cambio.

Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed
tracert -h 8 -w 500 vpn.corp.example
Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match 'VPN' | Select-Object DisplayName, Action

Cuando la red de comparación funciona, la red original sigue fallando y los eventos permanecen vacíos, el sospechoso restante es la ruta y no el host. Entréguelo al responsable de la red como una afirmación concreta, con ambos resultados de comparación adjuntos. Es un lugar mejor para detenerse que un perfil de cortafuegos desactivado.