Blokerer firewallen VPN’en? En trinvis kontrol

Én VPN-timeout beviser, at der ikke er ankommet et brugbart svar, og det beviser intet om hvorfor. Profilen kan angive den forkerte port, serveren kan være nede, eller anmodningen kan ankomme uden en fungerende returvej. Hver af disse efterlader et forskelligt spor, og sporet er det, der fortæller dig, hvilken regel du skal røre ved. Gå gennem de fire trin nedenfor i rækkefølge. Stop, så snart et af dem forklarer symptomet.

Trin 1: bekræft serveren og transporten

Læs servernavn, transport og port fra operatørens aktuelle profil i stedet for fra en lokal ændring. En port, der er ændret på din laptop, kan ikke oprette en lytter på en offentlig server, og den uoverensstemmelse giver en timeout, der er identisk med en blokering. Hvis profilen tilbyder en understøttet alternativ transport, så noter den som fallback og ikke som løsning. Slå navnet op, og sammenlign svaret med den adresse, operatøren har offentliggjort.

En forældet DNS-post sender klienten til en vært, der aldrig svarede. Det er en anden fejl, der efterligner et filter, og den koster én forespørgsel at udelukke.

Skriv begge værdier i billetten. Hver senere sammenligning bruger dem, og en billet uden dem starter undersøgelsen forfra.

Trin 2: bevis stien med én kontrolleret sammenligning

Hold enheden og profilen uændrede, og prøv et andet betroet adgangsnetværk. Hvis tunnelen kommer op der, er forskellen den oprindelige sti eller dens politik. Hvis en anden godkendt enhed virker på det oprindelige netværk, er forskellen den første enhed. En af de to sammenligninger er næsten altid afgørende.

Fuldfør først ethvert legitimt netværkslogin, fordi en captive portal ligner en blokering, indtil den er gennemført.

Test den port, du faktisk bruger, og behandl et TCP-resultat som information 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

Et vellykket TCP-håndtryk på 443 betyder, at en lytter svarede der. Det siger intet om en UDP-lytter på 51820 og intet om, hvorvidt forhandlingen blev fuldført.

Trin 3: læs sikkerhedshændelserne for fejltidspunktet

Firewall-hændelser er det stærkeste tilgængelige bevis, og de har et forbehold, der er værd at nævne først. Logning er slået fra i mange standardprofiler, så kontroller, om den relevante profil logger drops, før du læser en tom log som bevis på uskyld. Når logningen er slået til, angiver hændelsen reglen, retningen og adresserne, hvilket er præcis, hvad en regelændring har brug for. Programregler og portregler er separate objekter, og administreret politik kan tilsidesætte en lokal indstilling. Bekræft, hvilken klient og hvilken tjeneste en regel faktisk dækker.

Indsaml profiltilstanden og de seneste hændelser fra den maskine, der fejlede, ikke fra en nabovært.

Læs hændelsestiden op mod tidspunktet for dit testforsøg, fordi et matchende regelnavn med et andet tidsstempel er en tilfældighed.

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, så spørg, om anmodningen overhovedet nåede lytteren. En ankommende pakke uden svar er et videresendelses- eller returruteproblem. En anmodning, der aldrig dukker op, er et filtrerings- eller adresseringsproblem.

Trin 4: test videresendelse, når tunnelen er oppe

En firewall kan tillade sessionen og stadig afvise alt, hvad sessionen vil nå. Videresendelses-sysctls, NAT-regler og returruter ligger alle efter autentificering, og en bred undtagelse for VPN-porten reparerer ingen af dem. Test én intern destination og én internetdestination hver for sig, fordi de normalt fejler af forskellige grunde. Hvis interne navne fejler, men adresser virker, så kig på pushet DNS før nogen regel.

Kør de tre kontroller nedenfor på serveren, mens en klient er forbundet og forsøger den fejlende anmodning.

Tællerne på tunnelinterfacet er pointen, fordi de viser, om pakker kom ind, og om noget forlod.

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

Når pakker ankommer på tunnelen, og intet forlader mod destinationen, er videresendelse eller NAT den mistænkte. Når intet ankommer, er sessionen oppe, men klienten sender ikke, og klientens rutetabel er stedet at kigge.

Kontroller rettelsen, og fjern det, der ikke hjalp

Efter en godkendt rettelse gentages præcis den test, der fejlede, og resultatet noteres mod samme profil og enhed. Fjern derefter enhver midlertidig undtagelse, der ikke ændrede resultatet, fordi ubrugte undtagelser hober sig op, og hver enkelt er en beslutning, som ingen husker at have taget. Hold det, der er tilbage, snævert: én destination, én port, én retning, én ejer.

Kør de samme tre kommandoer igen, og sammenlign dem med de output, du gemte før æ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 sammenligningsnetværket virker, det oprindelige netværk stadig fejler, og hændelserne forbliver tomme, er den resterende mistænkte stien og ikke værten. Giv det videre til netværksejeren som en konkret udtalelse med begge sammenligningsresultater vedlagt. Det er et bedre sted at stoppe end en deaktiveret firewall-profil.