Blockerar brandväggen VPN:en? En kontroll steg för steg

En enda VPN-timeout bevisar att inget användbart svar kom fram, och bevisar ingenting om varför. Profilen kan ange fel port, servern kan ligga nere, eller begäran kan komma fram utan en fungerande returväg. Var och en av dessa lämnar ett olika spår, och spåret är det som säger vilken regel du ska röra. Gå igenom de fyra stegen nedan i ordning. Stanna så snart ett av dem förklarar symptomet.

Steg 1: bekräfta servern och transporten

Läs servernamn, transport och port från operatörens aktuella profil och inte från en lokal ändring. En port som ändrats på din laptop kan inte skapa en lyssnare på en publik server, och den diskrepansen ger en timeout som är identisk med en blockering. Om profilen erbjuder en stödd alternativ transport, notera den som reserv och inte som lösning. Slå upp namnet och jämför svaret med adressen som operatören publicerat.

En inaktuell DNS-post skickar klienten till en värd som aldrig svarade. Det är ett annat fel som härmar ett filter, och det kostar en enda fråga att utesluta.

Skriv båda värdena i ärendet. Varje senare jämförelse använder dem, och ett ärende utan dem börjar utredningen om.

Steg 2: bevisa vägen med en kontrollerad jämförelse

Låt enheten och profilen vara oförändrade och prova ett annat betrott åtkomstnät. Om tunneln kommer upp där är skillnaden den ursprungliga vägen eller dess policy. Om en andra godkänd enhet fungerar på det ursprungliga nätet är skillnaden den första enheten. En av dessa två jämförelser är nästan alltid avgörande.

Slutför först all legitim nätverksinloggning, eftersom en captive portal ser ut som en blockering tills den är klar.

Testa den port du faktiskt använder, och behandla ett TCP-resultat som information om TCP enbart.

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

En lyckad TCP-handskakning på 443 säger att en lyssnare svarade där. Den säger ingenting om en UDP-lyssnare på 51820, och ingenting om förhandlingen slutfördes.

Steg 3: läs säkerhetshändelserna för felets ögonblick

Brandväggshändelser är det starkaste beviset som finns, och de bär ett förbehåll som är värt att nämna först. Loggning är avstängd i många standardprofiler, så kontrollera om den aktuella profilen loggar dropp innan du läser en tom logg som bevis på oskuld. När loggningen är på anger händelsen regeln, riktningen och adresserna, vilket är precis vad en regeländring behöver. Programregler och portregler är separata objekt, och hanterad policy kan åsidosätta en lokal inställning. Bekräfta vilken klient och vilken tjänst en regel faktiskt täcker.

Samla profiltillståndet och de senaste händelserna från maskinen som misslyckades, inte från en grannvärd.

Läs händelsetiden mot tiden för ditt testförsök, eftersom ett matchande regelnamn med en annan tidsstämpel är en tillfällighet.

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

På en server du administrerar, fråga om begäran överhuvudtaget nådde lyssnaren. Ett paket som anländer utan svar är ett vidarebefordrings- eller returvägsproblem. En begäran som aldrig dyker upp är ett filtrerings- eller adresseringsproblem.

Steg 4: testa vidarebefordran efter att tunneln är uppe

En brandvägg kan tillåta sessionen och ändå neka allt som sessionen vill nå. Vidarebefordrings-sysctl, NAT-regler och returvägar ligger alla efter autentisering, och ett brett undantag för VPN-porten reparerar ingen av dem. Testa en intern destination och en internetdestination var för sig, eftersom de oftast misslyckas av olika skäl. Om interna namn misslyckas men adresser fungerar, titta på den pushade DNS:en före någon regel.

Kör de tre kontrollerna nedan på servern medan en klient är ansluten och försöker med den misslyckade begäran.

Räknarna på tunnelgränssnittet är poängen, eftersom de visar om paket kom in och om något gick ut.

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

När paket anländer på tunneln och ingenting går ut mot destinationen är vidarebefordran eller NAT den misstänkte. När ingenting anländer är sessionen uppe men klienten skickar inte, och platsen att titta på är klientens routingtabell.

Kontrollera åtgärden och ta bort det som inte hjälpte

Efter en godkänd korrigering, upprepa exakt det test som misslyckades och registrera resultatet mot samma profil och enhet. Ta sedan bort varje tillfälligt undantag som inte ändrade resultatet, eftersom oanvända undantag hopar sig och varje sådant är ett beslut som ingen minns. Håll det som återstår smalt: en destination, en port, en riktning, en ägare.

Kör samma tre kommandon igen och jämför dem med utdata du sparade före ändringen.

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

När jämförelsenätet fungerar, det ursprungliga nätet fortfarande misslyckas och händelserna förblir tomma, är den kvarvarande misstänkte vägen och inte värden. Lämna det till nätverksägaren som ett konkret påstående, med båda jämförelseresultaten bifogade. Det är en bättre plats att stanna på än en avstängd brandväggsprofil.