Blokkerer brannmuren VPN-en? Ei trinnvis kontroll

Eitt VPN-tidsavbrot provar at det ikkje kom noko brukbart svar, og det provar ingenting om kvifor. Profilen kan oppgje feil port, tenaren kan vere nede, eller førespurnaden kan kome fram utan ein fungerande returveg. Kvar av desse etterlèt eit ulikt spor, og sporet er det som fortel deg kva regel du skal røre. Gå gjennom dei fire trinna nedanfor i rekkjefølgje. Stopp så snart eitt av dei forklarer symptomet.

Trinn 1: stadfest tenaren og transporten

Les tenarnamnet, transporten og porten frå den gjeldande profilen til operatøren og ikkje frå ei lokal endring. Ein port som er endra på laptoppen din kan ikkje opprette ein lyttar på ein offentleg tenar, og det avviket gjev eit tidsavbrot som er identisk med ein blokkering. Viss profilen tilbyr ein støtta alternativ transport, noter han som reserve og ikkje som løysing. Slå opp namnet og samanlikn svaret med adressa operatøren har publisert.

Ein utdatert DNS-post sender klienten til ein vert som aldri svara. Det er ein annan feil som etterliknar eit filter, og han kostar éi spørjing å utelukke.

Skriv begge verdiane i saka. Kvar seinare samanlikning brukar dei, og ei sak utan dei startar granskinga på nytt.

Trinn 2: prov stien med éi kontrollert samanlikning

Hald eininga og profilen uendra og prøv eit anna klarert tilgangsnettverk. Viss tunnelen kjem opp der, er skilnaden den opphavlege stien eller politikken hans. Viss ei anna godkjend eining verkar på det opphavlege nettverket, er skilnaden den første eininga. Éi av desse to samanlikningane er nesten alltid avgjerande.

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

Test porten du faktisk brukar, og handsam eit TCP-resultat som informasjon om TCP åleine.

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

Eit vellukka TCP-handtrykk på 443 tyder på at ein lyttar svara der. Det seier ingenting om ein UDP-lyttar på 51820, og ingenting om forhandlinga vart fullført.

Trinn 3: les tryggingstilfella for feiltidspunktet

Brannmurhendingar er det sterkaste provet som finst, og dei har eit atterhald det er verdt å nemne først. Logging er slått av i mange standardprofilar, så sjekk om den aktuelle profilen loggar dropp før du les ein tom logg som prov på uskuld. Når logginga er på, namngjev hendinga regelen, retninga og adressene, som er nøyaktig det ei regelendring treng. Applikasjonsreglar og portreglar er separate objekt, og styrt policy kan overstyre ei lokal innstilling. Stadfest kva klient og kva teneste ein regel faktisk dekkjer.

Samle profiltilstanden og dei siste hendingane frå maskina som feila, ikkje frå ein nabovert.

Les hendingstida mot tidspunktet for testforsøket ditt, fordi eit samsvarande regelnavn med eit anna tidsstempel er eit tilfelle.

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å ein tenar du administrerer, spør om førespurnaden i det heile nådde lyttaren. Ein pakke som kjem utan svar er eit videresendings- eller returruteproblem. Ein førespurnad som aldri dukkar opp er eit filtrerings- eller adresseringsproblem.

Trinn 4: test videresending etter at tunnelen er oppe

Ein brannmur kan tillate økta og likevel avvise alt økta vil nå. Videresendings-sysctl, NAT-reglar og returruter ligg alle etter autentisering, og eit breitt unntak for VPN-porten reparerer ingen av dei. Test éin intern destinasjon og éin internettdestinasjon kvar for seg, fordi dei vanlegvis feilar av ulike grunnar. Viss interne namn feilar medan adresser verkar, sjå på den pusja DNS-en før nokon regel.

Køyr dei tre kontrollane nedanfor på tenaren medan ein klient er tilkopla og prøver den feilande førespurnaden.

Teljarane på tunnelgrensesnittet er poenget, fordi dei viser om pakkar kom inn og om noko gjekk ut.

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

Når pakkar kjem til tunnelen og ingenting går ut mot destinasjonen, er videresending eller NAT den mistenkte. Når ingenting kjem, er økta oppe men klienten sender ikkje, og staden å sjå er rutetabellen til klienten.

Kontroller rettinga og fjern det som ikkje hjelpte

Etter ei godkjend retting, gjer nøyaktig den same testen som feila på nytt og registrer resultatet mot same profil og eining. Fjern deretter eitkvart mellombels unntak som ikkje endra resultatet, fordi ubrukte unntak hopar seg opp og kvart av dei er ei avgjerd ingen hugsar å ha teke. Hald det som står att smalt: éin destinasjon, éin port, éi retning, éin eigar.

Køyr dei same tre kommandoane på nytt og samanlikn dei med utdataa du lagra før endringa.

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 samanlikningsnettverket verkar, det opphavlege nettverket framleis feilar og hendingane blir tomme, er den gjenverande mistenkte stien og ikkje verten. Overlever dette til nettverkseigaren som ei konkret utsegn, med begge samanlikningsresultata vedlagde. Det er ein betre stad å stoppe enn ein deaktivert brannmurprofil.