El tallafoc bloqueja la VPN? Una comprovació pas a pas

Un sol temps d’espera esgotat de la VPN demostra que no ha arribat cap resposta utilitzable, i no demostra res sobre el perquè. El perfil pot indicar un port equivocat, el servidor pot estar aturat o la sol·licitud pot arribar sense un camí de retorn funcional. Cadascun d’aquests casos deixa una traça diferent, i la traça és el que us diu quina regla cal tocar. Recorreu les quatre etapes següents per ordre. Atureu-vos tan bon punt una d’elles expliqui el símptoma.

Pas 1: confirmeu el servidor i el transport

Llegiu el nom del servidor, el transport i el port del perfil actual de l’operador i no d’una edició local. Un port canviat al vostre portàtil no pot crear un oient en un servidor públic, i aquesta discrepància produeix un temps d’espera idèntic a un bloqueig. Si el perfil ofereix un transport alternatiu compatible, anoteu-lo com a alternativa i no com a solució. Resoleu el nom i compareu la resposta amb l’adreça que l’operador ha publicat.

Un registre DNS antic envia el client a un amfitrió que mai no ha respost. És una altra fallada que imita un filtre, i descartar-la costa una sola consulta.

Escriviu els dos valors al tiquet. Totes les comparacions posteriors els fan servir, i un tiquet sense ells reinicia la investigació.

Pas 2: demostreu el camí amb una única comparació controlada

Mantingueu el dispositiu i el perfil sense canvis i proveu una altra xarxa d’accés de confiança. Si el túnel s’aixeca allà, la diferència és el camí original o la seva política. Si un segon dispositiu aprovat funciona a la xarxa original, la diferència és el primer dispositiu. Una d’aquestes dues comparacions és gairebé sempre decisiva.

Completeu primer qualsevol inici de sessió de xarxa legítim, perquè un portal captiu sembla un bloqueig fins que no s’ha completat.

Proveu el port que feu servir de debò, i tracteu un resultat TCP com a informació nomé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 intercanvi TCP correcte al port 443 diu que allà hi ha respost un oient. No diu res sobre un oient UDP al 51820 ni sobre si la negociació s’ha completat.

Pas 3: llegiu els esdeveniments de seguretat del moment de la fallada

Els esdeveniments del tallafoc són la prova més sòlida disponible, i porten una advertència que val la pena dir primer. El registre està desactivat en molts perfils per defecte, així que comproveu si el perfil pertinent enregistra descarts abans de llegir un registre buit com a prova d’innocència. Quan el registre està actiu, l’esdeveniment indica la regla, la direcció i les adreces, que és exactament el que cal per canviar una regla. Les regles d’aplicació i les regles de port són objectes separats, i la política gestionada pot anul·lar un paràmetre local. Confirmeu quin client i quin servei cobreix realment una regla.

Recolliu l’estat del perfil i els esdeveniments recents de la màquina que ha fallat, no d’un amfitrió veí.

Llegiu l’hora de l’esdeveniment contra l’hora del vostre intent de prova, perquè un nom de regla coincident amb una marca de temps diferent és una casualitat.

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 administreu, pregunteu si la sol·licitud ha arribat al oient. Un paquet que arriba sense resposta és un problema de reenviament o de ruta de retorn. Una sol·licitud que no apareix mai és un problema de filtratge o d’adreçament.

Pas 4: proveu el reenviament un cop el túnel és aixecat

Un tallafoc pot permetre la sessió i negar tot el que la sessió vol assolir. Els sysctl de reenviament, les regles NAT i les rutes de retorn se situen després de l’autenticació, i una exempció àmplia per al port de la VPN no n’arregla cap. Proveu una destinació interna i una destinació d’internet per separat, perquè normalment fallen per motius diferents. Si els noms interns fallen però les adreces funcionen, mireu el DNS empès abans de qualsevol regla.

Executeu les tres comprovacions següents al servidor mentre un client hi és connectat i intenta la sol·licitud que falla.

Els comptadors de la interfície del túnel són el punt clau, perquè mostren si els paquets han entrat i si ha sortit res.

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

Quan arriben paquets al túnel i no en surt cap cap a la destinació, el sospitós és el reenviament o el NAT. Quan no n’arriba cap, la sessió és aixecada però el client no envia, i el lloc on mirar és la taula de rutes del client.

Comproveu la correcció i traieu el que no ha ajudat

Després d’una correcció aprovada, repetiu exactament la prova que ha fallat i enregistreu el resultat amb el mateix perfil i dispositiu. Després traieu qualsevol excepció temporal que no hagi canviat el resultat, perquè les excepcions no utilitzades s’acumulen i cadascuna és una decisió que ningú no recorda haver pres. Mantingueu el que quedi estret: una destinació, un port, una direcció, un responsable.

Torneu a executar les mateixes tres ordres i compareu-les amb les sortides que vau desar abans del canvi.

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

Quan la xarxa de comparació funciona, la xarxa original encara falla i els esdeveniments continuen buits, el sospitós restant és el camí i no l’amfitrió. Lliureu-ho al responsable de la xarxa com una afirmació concreta, amb els dos resultats de comparació adjunts. És un lloc millor per aturar-se que un perfil de tallafoc desactivat.