Blokkerer brannmuren VPN-en? En trinnvis kontroll

Én VPN-tidsavbrudd beviser at det ikke kom noe brukbart svar, og det beviser ingenting om hvorfor. Profilen kan oppgi feil port, serveren kan være nede, eller forespørselen kan komme fram uten en fungerende returvei. Hver av disse etterlater et ulikt spor, og sporet er det som forteller deg hvilken regel du skal røre. Gå gjennom de fire trinnene nedenfor i rekkefølge. Stopp så snart ett av dem forklarer symptomet.

Trinn 1: bekreft serveren og transporten

Les servernavnet, transporten og porten fra operatørens gjeldende profil og ikke fra en lokal endring. En port som er endret på laptopen din kan ikke opprette en lytter på en offentlig server, og det avviket gir en tidsavbrudd som er identisk med en blokkering. Hvis profilen tilbyr en støttet alternativ transport, noter den som reserve og ikke som løsning. Slå opp navnet og sammenlign svaret med adressen operatøren har publisert.

En utdatert DNS-post sender klienten til en vert som aldri svarte. Det er en annen feil som etterligner et filter, og den koster én spørring å utelukke.

Skriv begge verdiene i saken. Hver senere sammenligning bruker dem, og en sak uten dem starter undersøkelsen på nytt.

Trinn 2: bevis stien med én kontrollert sammenligning

Hold enheten og profilen uendret og prøv et annet klarert tilgangsnettverk. Hvis tunnelen kommer opp der, er forskjellen den opprinnelige stien eller dens policy. Hvis en annen godkjent enhet virker på det opprinnelige nettverket, er forskjellen den første enheten. Én av disse to sammenligningene er nesten alltid avgjørende.

Fullfør først all legitim nettverksinnlogging, fordi en captive portal ser ut som en blokkering til den er fullført.

Test porten du faktisk bruker, og behandle et TCP-resultat som informasjon om TCP alene.

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

En vellykket TCP-håndtrykk på 443 betyr at en lytter svarte der. Det sier ingenting om en UDP-lytter på 51820, og ingenting om forhandlingen ble fullført.

Trinn 3: les sikkerhetshendelsene for feiltidspunktet

Brannmurhendelser er det sterkeste beviset som finnes, og de har et forbehold det er verdt å nevne først. Logging er slått av i mange standardprofiler, så sjekk om den aktuelle profilen logger dropp før du leser en tom logg som bevis på uskyld. Når loggingen er på, navngir hendelsen regelen, retningen og adressene, som er nøyaktig det en regelendring trenger. Applikasjonsregler og portregler er separate objekter, og administrert policy kan overstyre en lokal innstilling. Bekreft hvilken klient og hvilken tjeneste en regel faktisk dekker.

Samle profiltilstanden og de siste hendelsene fra maskinen som feilet, ikke fra en nabovert.

Les hendelsestiden mot tidspunktet for testforsøket ditt, fordi et samsvarende regelnavn med et annet tidsstempel er en tilfeldighet.

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 administrerer, spør om forespørselen i det hele tatt nådde lytteren. En pakke som ankommer uten svar er et videresendings- eller returruteproblem. En forespørsel som aldri dukker opp er et filtrerings- eller adresseringsproblem.

Trinn 4: test videresending etter at tunnelen er oppe

En brannmur kan tillate økten og likevel avvise alt økten vil nå. Videresendings-sysctl, NAT-regler og returruter ligger alle etter autentisering, og et bredt unntak for VPN-porten reparerer ingen av dem. Test én intern destinasjon og én internettdestinasjon hver for seg, fordi de vanligvis feiler av ulike grunner. Hvis interne navn feiler mens adresser virker, se på den pushede DNS-en før noen regel.

Kjør de tre kontrollene nedenfor på serveren mens en klient er tilkoblet og forsøker den feilende forespørselen.

Tellerne på tunnelgrensesnittet er poenget, fordi de viser om pakker kom inn og om noe gikk ut.

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

Når pakker ankommer tunnelen og ingenting går ut mot destinasjonen, er videresending eller NAT den mistenkte. Når ingenting ankommer, er økten oppe men klienten sender ikke, og stedet å se er klientens rutetabell.

Kontroller rettelsen og fjern det som ikke hjalp

Etter en godkjent rettelse, gjenta nøyaktig testen som feilet og registrer resultatet mot samme profil og enhet. Fjern deretter ethvert midlertidig unntak som ikke endret resultatet, fordi ubrukte unntak hoper seg opp og hvert av dem er en beslutning ingen husker å ha tatt. Hold det som gjenstår smalt: én destinasjon, én port, én retning, én eier.

Kjør de samme tre kommandoene på nytt og sammenlign dem med utdataene du lagret før endringen.

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 sammenligningsnettverket virker, det opprinnelige nettverket fortsatt feiler og hendelsene forblir tomme, er den gjenværende mistenkte stien og ikke verten. Overlever dette til nettverkseieren som en konkret uttalelse, med begge sammenligningsresultatene vedlagt. Det er et bedre sted å stoppe enn en deaktivert brannmurprofil.