Il firewall blocca la VPN? Una verifica passo per passo

Un solo timeout della VPN prova che non è arrivata alcuna risposta utilizzabile, e non prova nulla sul perché. Il profilo può indicare la porta sbagliata, il server può essere inattivo, oppure la richiesta può arrivare senza un percorso di ritorno funzionante. Ognuno di questi casi lascia una traccia diversa, ed è la traccia a dirti quale regola toccare. Segui le quattro tappe qui sotto nell’ordine. Fermati appena una di esse spiega il sintomo.

Tappa 1: conferma il server e il trasporto

Leggi il nome del server, il trasporto e la porta dal profilo attuale dell’operatore e non da una modifica locale. Una porta modificata sul tuo portatile non può creare un listener su un server pubblico, e quella discrepanza produce un timeout identico a un blocco. Se il profilo offre un trasporto alternativo supportato, annotalo come ripiego e non come correzione. Risolvi il nome e confronta la risposta con l’indirizzo pubblicato dall’operatore.

Un record DNS obsoleto manda il client verso un host che non ha mai risposto. È un altro guasto che imita un filtro, e costa una sola query per escluderlo.

Scrivi entrambi i valori nel ticket. Ogni confronto successivo li usa, e un ticket senza di essi riparte dall’inizio.

Tappa 2: dimostra il percorso con un solo confronto controllato

Lascia invariati dispositivo e profilo e prova un’altra rete di accesso fidata. Se il tunnel si alza lì, la differenza è il percorso originale o la sua politica. Se un secondo dispositivo approvato funziona sulla rete originale, la differenza è il primo dispositivo. Uno di questi due confronti è quasi sempre decisivo.

Completa prima qualsiasi accesso di rete legittimo, perché un portale captive sembra un blocco finché non è concluso.

Prova la porta che usi davvero, e tratta un risultato TCP come informazione solo su 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 riuscito sulla porta 443 dice che lì ha risposto un listener. Non dice nulla su un listener UDP sulla 51820, né se la negoziazione è stata completata.

Tappa 3: leggi gli eventi di sicurezza del momento del guasto

Gli eventi del firewall sono la prova più solida disponibile, e portano un avvertimento che vale la pena dire per primo. La registrazione è disattivata in molti profili predefiniti, quindi controlla se il profilo interessato registra gli scarti prima di leggere un registro vuoto come prova di innocenza. Quando la registrazione è attiva, l’evento indica la regola, la direzione e gli indirizzi, cioè esattamente ciò che serve a una modifica di regola. Le regole delle applicazioni e le regole delle porte sono oggetti separati, e una politica gestita può prevalere su un’impostazione locale. Conferma quale client e quale servizio copre davvero una regola.

Raccogli lo stato del profilo e gli eventi recenti dalla macchina che ha fallito, non da un host vicino.

Confronta l’ora dell’evento con l’ora del tuo tentativo di test, perché un nome di regola corrispondente con un timestamp diverso è una coincidenza.

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

Su un server che amministri, chiedi se la richiesta è arrivata al listener. Un pacchetto che arriva senza risposta è un problema di inoltro o di rotta di ritorno. Una richiesta che non compare mai è un problema di filtraggio o di indirizzamento.

Tappa 4: prova l’inoltro dopo che il tunnel è alzato

Un firewall può consentire la sessione e comunque negare tutto ciò che la sessione vuole raggiungere. I sysctl di inoltro, le regole NAT e le rotte di ritorno stanno tutti dopo l’autenticazione, e un’esenzione ampia per la porta VPN non ne ripara nessuna. Prova una destinazione interna e una destinazione internet separatamente, perché di solito falliscono per motivi diversi. Se i nomi interni falliscono ma gli indirizzi funzionano, guarda il DNS spinto prima di qualsiasi regola.

Esegui i tre controlli qui sotto sul server mentre un client è connesso e tenta la richiesta che fallisce.

I contatori dell’interfaccia del tunnel sono il punto, perché mostrano se i pacchetti sono entrati e se qualcosa è uscito.

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

Quando i pacchetti arrivano sul tunnel e nulla esce verso la destinazione, il sospetto è l’inoltro o il NAT. Quando non arriva nulla, la sessione è alzata ma il client non invia, e il posto da guardare è la tabella delle rotte del client.

Verifica la correzione e rimuovi ciò che non ha aiutato

Dopo una correzione approvata, ripeti esattamente il test che ha fallito e registra il risultato con lo stesso profilo e dispositivo. Poi rimuovi ogni eccezione temporanea che non ha cambiato l’esito, perché le eccezioni inutilizzate si accumulano e ciascuna è una decisione che nessuno ricorda di aver preso. Mantieni stretto ciò che resta: una destinazione, una porta, una direzione, un responsabile.

Riesegui gli stessi tre comandi e confrontali con gli output che hai salvato prima della modifica.

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

Quando la rete di confronto funziona, la rete originale continua a fallire e gli eventi restano vuoti, il sospetto rimasto è il percorso e non l’host. Consegnialo al responsabile di rete come affermazione precisa, con entrambi i risultati di confronto allegati. È un punto di arresto migliore di un profilo firewall disattivato.