O devasa bloquea a VPN? Unha comprobación paso a paso

Un só tempo de espera esgotado da VPN demostra que non chegou ningunha resposta utilizábel, e non demostra nada sobre o porqué. O perfil pode indicar o porto equivocado, o servidor pode estar caído ou a solicitude pode chegar sen un camiño de retorno funcional. Cada un deses casos deixa unha traza distinta, e a traza é o que lle di que regra tocar. Percorra as catro etapas seguintes por orde. Detéñase en canto unha delas explique o síntoma.

Paso 1: confirme o servidor e o transporte

Lea o nome do servidor, o transporte e o porto do perfil actual do operador e non dunha edición local. Un porto cambiado no seu portátil non pode crear un oínte nun servidor público, e esa discrepancia produce un tempo de espera idéntico a un bloqueo. Se o perfil ofrece un transporte alternativo compatíbel, anóteo como respaldo e non como solución. Resolva o nome e compare a resposta co enderezo que o operador publicou.

Un rexistro DNS obsoleto envía o cliente a un servidor que nunca respondeu. É outro fallo que imita un filtro, e descartalo custa unha soa consulta.

Escriba os dous valores no tícket. Todas as comparacións posteriores úsaos, e un tícket sen eles reinicia a investigación.

Paso 2: demostre o camiño cunha única comparación controlada

Manteña o dispositivo e o perfil sen cambios e probe outra rede de acceso de confianza. Se o túnel se levanta alí, a diferenza é o camiño orixinal ou a súa política. Se un segundo dispositivo aprobado funciona na rede orixinal, a diferenza é o primeiro dispositivo. Unha desas dúas comparacións é case sempre decisiva.

Complete primeiro calquera inicio de sesión de rede lexítimo, porque un portal cativo parece un bloqueo ata que se completa.

Probe o porto que realmente usa, e trate un resultado TCP como información só 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 apretón de mans TCP correcto no porto 443 di que alí respondeu un oínte. Non di nada sobre un oínte UDP no 51820 nin sobre se se completou a negociación.

Paso 3: lea os eventos de seguridade do momento do fallo

Os eventos do devasa son a proba máis sólida dispoñíbel, e levan unha advertencia que convén dicir primeiro. O rexistro está desactivado en moitos perfís predeterminados, así que comprobe se o perfil correspondente rexistra descartes antes de ler un rexistro baleiro como proba de inocencia. Cando o rexistro está activo, o evento indica a regra, a dirección e os enderezos, que é exactamente o que necesita un cambio de regra. As regras de aplicación e as regras de porto son obxectos separados, e a política xestionada pode anular un axuste local. Confirme que cliente e que servizo cobre realmente unha regra.

Recolla o estado do perfil e os eventos recentes da máquina que fallou, non dun servidor veciño.

Lea a hora do evento fronte á hora do seu intento de proba, porque un nome de regra coincidente cunha marca de tempo distinta é unha casualidade.

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

Nun servidor que administre, pregunte se a solicitude chegou sequera ao oínte. Un paquete que chega sen resposta é un problema de reenvío ou de ruta de retorno. Unha solicitude que nunca aparece é un problema de filtrado ou de direccionamento.

Paso 4: probe o reenvío unha vez levantado o túnel

Un devasa pode permitir a sesión e aínda así denegar todo o que a sesión quere acadar. Os sysctl de reenvío, as regras NAT e as rutas de retorno están todos despois da autenticación, e unha exención ampla para o porto da VPN non repara ningún deles. Probe un destino interno e un destino de internet por separado, porque adoitan fallar por motivos distintos. Se os nomes internos fallan pero os enderezos funcionan, mire o DNS empurrado antes que calquera regra.

Execute as tres comprobacións seguintes no servidor mentres un cliente está conectado e tenta a solicitude que falla.

Os contadores da interface do túnel son o punto clave, porque mostran se entraron paquetes e se saíu algo.

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

Cando chegan paquetes ao túnel e non sae nada cara ao destino, o sospeitoso é o reenvío ou o NAT. Cando non chega nada, a sesión está levantada pero o cliente non envía, e o lugar onde mirar é a táboa de rutas do cliente.

Comprobe a corrección e elimine o que non axudou

Tras unha corrección aprobada, repita exactamente a proba que fallou e rexistre o resultado co mesmo perfil e dispositivo. Despois elimine calquera excepción temporal que non cambiase o resultado, porque as excepcións sen uso acumúlanse e cada unha é unha decisión que ninguén lembra ter tomado. Manteña estreito o que quede: un destino, un porto, unha dirección, un responsable.

Volve executar os mesmos tres comandos e compáraos coas saídas que gardou antes do 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

Cando a rede de comparación funciona, a rede orixinal segue fallando e os eventos permanecen baleiros, o sospeitoso restante é o camiño e non o servidor. Entrégueo ao responsable da rede como unha afirmación concreta, cos dous resultados de comparación adxuntos. É un lugar mellor para deter a investigación que un perfil de devasa desactivado.