Blokkearret de firewall de VPN? In stap-foar-stap kontrôle

Ien VPN-time-out bewiist dat der gjin brûkber antwurd oankaam, en it bewiist neat oer wêrom. It profyl kin de ferkearde poarte neame, de server kin del wêze, of it fersyk kin oankomme sûnder in wurkjend werompaad. Elk dêrfan lit in oar spoar efter, en it spoar is wat jo seit hokker regel jo oanreitsje moatte. Wurkje de fjouwer stadia hjirûnder op folchoarder troch. Stop sa gau as ien fan harren it symptoom ferklearret.

Stap 1: befêstigje de server en it ferfier

Lês de servernamme, it ferfier en de poarte út it hjoeddeiske profyl fan de operator, net út in pleatslike wiziging. In poarte dy’t op jo laptop feroare is, kin gjin listener op in iepenbiere server meitsje, en dat missetting jout in time-out dy’t identyk is oan in blokkade. As it profyl in stipe alternatyf ferfier biedt, notearje it dan as fallback en net as oplossing. Los de namme op en ferlykje it antwurd mei it adres dat de operator publisearre hat.

In ferâldere DNS-record stjoert de klient nei in host dy’t nea antwurde. Dat is in oare flater dy’t in filter neibeart, en it kostet ien query om dy út te sluten.

Skriuw beide wearden yn it ticket. Elk letter ferliking brûkt se, en in ticket sûnder se begjint it ûndersyk op ’e nij.

Stap 2: bewize it paad mei ien kontrolearre ferliking

Hâld it apparaat en it profyl ûnferoare en probearje in oar fertroud tagongsnetwurk. As de tunnel dêr opkomt, is it oarspronklike paad of syn belied it ferskil. As in twadde goedkard apparaat op it oarspronklike netwurk wurket, is it earste apparaat it ferskil. Ien fan dy twa ferlikingen is hast altyd beslissend.

Foltóchje earst elke legitime netwurk-oanmelding, want in captive portal liket op in blokkade oant it dien is.

Test de poarte dy’t jo echt brûke, en behannelje in TCP-resultaat as ynformaasje oer TCP allinnich.

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

In suksesfolle TCP-hânskikking op 443 seit dat dêr in listener antwurde. It seit neat oer in UDP-listener op 51820, en neat oer oft de ûnderhanneling foltôge is.

Stap 3: lês de befeiligingsbarren foar it momint fan it mislearjen

Firewall-barren binne it sterkste bewiis dat beskikber is, en se drage in foarbehâld dat it wurdich is om earst te neamen. Logboekhâlding is útskeakele yn in protte standertprofilen, kontrolearje dus oft it oanbelangjende profyl drops looit foardat jo in leech log lêze as bewiis fan ûnskuld. As de loghâlding aktyf is, neamt it barren de regel, de rjochting en de adressen, dat is krekt wat in regelwiziging nedich hat. Tapassingsregels en poarteregels binne aparte objekten, en beheard belied kin in pleatslike ynstelling oerskriuwe. Befêstigje hokker klient en hokker tsjinst in regel eins dekt.

Sammelje de profylstân en de resinte barren fan ’e masine dy’t mislearre, net fan in buormasine.

Lês de barrentiid tsjin ’e tiid fan jo testpoging, want in oerienkommende regelnammme mei in oar tiidstimpel is in tafal.

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

Freegje op in server dy’t jo beheare oft it fersyk uberhaupt by de listener oankaam. In oankommend pakket sûnder antwurd is in troerstjoerings- of weromrûteprobleem. In fersyk dat nea ferskynt is in filter- of adressearringprobleem.

Stap 4: test troerstjoering neidat de tunnel op is

In firewall kin de sesje tastean en dochs alles wegerje dat de sesje berikke wol. Troerstjoerings-sysctls, NAT-regels en weromrûtes steane allegear nei autentikaasje, en in brede útsûndering foar de VPN-poarte reparearret gjin ien fan harren. Test ien yntern bestimming en ien ynternetbestimming apart, want se mislearje meastentiids om ferskillende redenen. As ynterne nammen mislearje mar adressen wurkje, sjoch dan nei de pushte DNS foardat jo nei in regel sjogge.

Fier de trije kontrôles hjirûnder út op ’e server wylst in klient ferbûn is en it mislearjende fersyk probearret.

De tellers op ’e tunnelinterface binne it punt, want se litte sjen oft pakketten ynkamen en oft der wat útgong.

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

As pakketten op ’e tunnel oankomme en der neat nei de bestimming útgiet, is troerstjoering of NAT de fertochte. As der hielendal neat oankomt, is de sesje op mar stjoert de klient net, en de rûtetabel fan ’e klient is it plak om te sjen.

Kontrolearje de repaaraasje en ferwiderje wat net holp

Nei in goedkarde korreksje werhelje jo krekt de test dy’t mislearre en notearje it resultaat tsjin itselde profyl en apparaat. Ferwiderje dan elke tydlike útsûndering dy’t it resultaat net feroare, want ûnbrûkte útsûnderingen sammelje har op en elk is in beslút dat nimmen him betinkt. Hâld wat oerbliuwt smel: ien bestimming, ien poarte, ien rjochting, ien eigner.

Fier deselde trije kommando’s op ’e nij út en ferlykje se mei de útfier dy’t jo foar de wiziging bewarre hawwe.

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

As it ferlikingsnetwurk wurket, it oarspronklike netwurk noch mislearret en de barren leech bliuwe, is de oerbliuwende fertochte it paad en net de host. Jou dat oan ’e netwurkeigner as in konkrete útspraak, mei beide ferlikingsresultaten taheakke. Dat is in better plak om te stopjen as in útskeakele firewallprofyl.