Blokkeert de firewall de VPN? Een controle stap voor stap

Eén VPN-time-out bewijst dat er geen bruikbaar antwoord aankwam, en bewijst niets over het waarom. Het profiel kan de verkeerde poort noemen, de server kan plat liggen, of het verzoek kan aankomen zonder werkende terugweg. Elk daarvan laat een ander spoor achter, en het spoor is wat je vertelt welke regel je moet aanraken. Doorloop de vier fasen hieronder in volgorde. Stop zodra een ervan het symptoom verklaart.

Fase 1: bevestig de server en het transport

Lees de servernaam, het transport en de poort uit het huidige profiel van de operator en niet uit een lokale wijziging. Een poort die op je laptop is gewijzigd kan geen listener op een openbare server maken, en die mismatch levert een time-out op die identiek is aan een blokkade. Biedt het profiel een ondersteund alternatief transport, noteer dat dan als terugvaloptie en niet als oplossing. Los de naam op en vergelijk het antwoord met het adres dat de operator heeft gepubliceerd.

Een verouderd DNS-record stuurt de client naar een host die nooit antwoordde. Dat is een andere fout die een filter nabootst, en het kost één query om die uit te sluiten.

Schrijf beide waarden in het ticket. Elke latere vergelijking gebruikt ze, en een ticket zonder beide begint het onderzoek opnieuw.

Fase 2: bewijs het pad met één gecontroleerde vergelijking

Houd het apparaat en het profiel ongewijzigd en probeer een ander vertrouwd toegangsnetwerk. Komt de tunnel daar omhoog, dan is het verschil het oorspronkelijke pad of het beleid ervan. Werkt een tweede goedgekeurd apparaat op het oorspronkelijke netwerk, dan is het verschil het eerste apparaat. Een van die twee vergelijkingen is bijna altijd beslissend.

Rond eerst elke legitieme netwerkaanmelding af, want een captive portal lijkt op een blokkade tot die is afgerond.

Test de poort die je daadwerkelijk gebruikt, en behandel een TCP-resultaat als informatie over TCP alleen.

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

Een geslaagde TCP-handshake op 443 zegt dat daar een listener antwoordde. Het zegt niets over een UDP-listener op 51820, en niets over of de onderhandeling is afgerond.

Fase 3: lees de beveiligingsgebeurtenissen voor het moment van falen

Firewallgebeurtenissen zijn het sterkste bewijs dat beschikbaar is, en ze dragen een voorbehoud dat het waard is eerst te noemen. Logging staat in veel standaardprofielen uit, dus controleer of het betreffende profiel drops vastlegt voordat je een leeg log leest als bewijs van onschuld. Staat logging aan, dan noemt de gebeurtenis de regel, de richting en de adressen, precies wat een regelwijziging nodig heeft. Applicatieregels en poortregels zijn aparte objecten, en beheerd beleid kan een lokale instelling overrulen. Bevestig welke client en welke dienst een regel werkelijk dekt.

Verzamel de profielstatus en de recente gebeurtenissen van de machine die faalde, niet van een buurhost.

Lees de gebeurtenistijd tegen de tijd van je testpoging, want een overeenkomende regelnaam met een andere tijdstempel is toeval.

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

Vraag op een server die je beheert of het verzoek de listener überhaupt bereikte. Een aankomend pakket zonder antwoord is een doorstuur- of terugrouteprobleem. Een verzoek dat nooit verschijnt is een filter- of adresseringsprobleem.

Fase 4: test doorsturen nadat de tunnel staat

Een firewall kan de sessie toestaan en toch alles weigeren wat de sessie wil bereiken. Doorstuur-sysctls, NAT-regels en terugroutes staan allemaal na authenticatie, en een brede uitzondering voor de VPN-poort repareert geen enkele daarvan. Test één interne bestemming en één internetbestemming apart, want die falen meestal om verschillende redenen. Als interne namen falen maar adressen werken, kijk dan naar de gepushte DNS vóór enige regel.

Voer de drie controles hieronder op de server uit terwijl een client verbonden is en het falende verzoek probeert.

De tellers op de tunnelinterface zijn het punt, want ze tonen of pakketten binnenkwamen en of er iets uitging.

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

Wanneer pakketten op de tunnel aankomen en er niets richting bestemming uitgaat, is doorsturen of NAT de verdachte. Wanneer er niets aankomt, staat de sessie maar stuurt de client niet, en de plek om te kijken is de routetabel van de client.

Controleer de correctie en verwijder wat niet hielp

Herhaal na een goedgekeurde correctie precies de test die faalde en leg het resultaat vast tegen hetzelfde profiel en apparaat. Verwijder daarna elke tijdelijke uitzondering die de uitkomst niet veranderde, want ongebruikte uitzonderingen stapelen zich op en elk ervan is een beslissing die niemand zich herinnert. Houd wat overblijft smal: één bestemming, één poort, één richting, één eigenaar.

Voer dezelfde drie commando’s opnieuw uit en vergelijk ze met de uitvoer die je voor de wijziging hebt opgeslagen.

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

Wanneer het vergelijkingsnetwerk werkt, het oorspronkelijke netwerk nog steeds faalt en de gebeurtenissen leeg blijven, is het pad en niet de host de resterende verdachte. Geef dat als een concrete uitspraak door aan de netwerkeigenaar, met beide vergelijkingsresultaten bijgevoegd. Dat is een betere plek om te stoppen dan een uitgeschakeld firewallprofiel.