Is die firewall die VPN aan die blokkeer? ’n Stap-vir-stap ondersoek

Een VPN-time-out bewys dat geen bruikbare antwoord aangekom het nie, en dit bewys niks oor hoekom nie. Die profiel noem dalk die verkeerde poort, die bediener is dalk af, of die versoek kom aan sonder ’n werkende terugpad. Elkeen daarvan laat ’n ander spoor, en die spoor is wat jou sê watter reël om te raak. Werk die vier fases hieronder in volgorde deur. Stop sodra een van hulle die simptoom verklaar.

Stap 1: bevestig die bediener en die transport

Lees die bedienernaam, transport en poort uit die operateur se huidige profiel eerder as uit ’n plaaslike wysiging. ’n Poort wat op jou skootrekenaar verander is, kan nie ’n luisteraar op ’n publieke bediener skep nie, en daardie wanverhouding lewer ’n time-out op wat identies aan ’n blokkade is. As die profiel ’n ondersteunde alternatiewe transport bied, noteer dit as ’n terugval eerder as as ’n oplossing. Los die naam op en vergelyk die antwoord met die adres wat die operateur gepubliseer het.

’n Verouderde DNS-rekord stuur die kliënt na ’n gasheer wat nooit geantwoord het nie. Dit is nog ’n fout wat ’n filter naboots, en dit kos een navraag om dit uit te skakel.

Skryf albei waardes in die kaartjie. Elke latere vergelyking gebruik hulle, en ’n kaartjie sonder hulle begin die ondersoek oor.

Stap 2: bewys die pad met een beheerde vergelyking

Hou die toestel en profiel onveranderd en probeer ’n ander vertroude toegangsnetwerk. As die tonnel daar opkom, is die oorspronklike pad of sy beleid die verskil. As ’n tweede goedgekeurde toestel op die oorspronklike netwerk werk, is die eerste toestel die verskil. Een van daardie twee vergelykings is byna altyd deurslaggewend.

Voltooi eers enige wettige netwerk-aanmelding, want ’n captive portal lyk soos ’n blokkade totdat dit klaar is.

Toets die poort wat jy werklik gebruik, en behandel ’n TCP-resultaat as inligting oor TCP alleen.

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

’n Suksesvolle TCP-handdruk op 443 sê ’n luisteraar het daar geantwoord. Dit sê niks oor ’n UDP-luisteraar op 51820 nie, en niks oor of die onderhandeling voltooi is nie.

Stap 3: lees die sekuriteitsgebeurtenisse vir die oomblik van mislukking

Firewall-gebeurtenisse is die sterkste bewyse beskikbaar, en hulle het ’n voorbehoud wat eerste genoem moet word. Aantekening is in baie verstekprofiele afgeskakel, so gaan na of die betrokke profiel druppels aanteken voordat jy ’n leë log as bewys van onskuld lees. Wanneer aantekening aan is, noem die gebeurtenis die reël, die rigting en die adresse, wat presies is wat ’n reëlverandering nodig het. Toepassingsreëls en poortreëls is aparte objekte, en bestuurde beleid kan ’n plaaslike instelling oorheers. Bevestig watter kliënt en watter diens ’n reël werklik dek.

Versamel die profieltoestand en die onlangse gebeurtenisse van die masjien wat misluk het, nie van ’n naburige gasheer nie.

Lees die gebeurtenistyd teen die tyd van jou toets, want ’n ooreenstemmende reëlnaam met ’n ander tydstempel is ’n toevalligheid.

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

Op ’n bediener wat jy administreer, vra of die versoek hoegenaamd by die luisteraar uitgekom het. ’n Aankomende pakkie sonder antwoord is ’n deurgee- of terugroeteprobleem. ’n Versoek wat nooit verskyn nie, is ’n filter- of adresseringsprobleem.

Stap 4: toets deurgee nadat die tonnel op is

’n Firewall kan die sessie toelaat en steeds alles weier wat die sessie wil bereik. Deurgee-sysctls, NAT-reëls en terugroetes sit almal ná verifikasie, en ’n breë vrystelling vir die VPN-poort herstel nie een daarvan nie. Toets een interne bestemming en een internetbestemming afsonderlik, want hulle misluk gewoonlik om verskillende redes. As interne name misluk maar adresse werk, kyk na gestuurde DNS voordat jy na enige reël kyk.

Voer die drie kontroles hieronder op die bediener uit terwyl ’n kliënt gekonnekteer is en die mislukkende versoek probeer.

Die tellers op die tonnelkoppelvlak is die punt, want hulle wys of pakkies ingegaan het en of iets uitgegaan het.

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

Wanneer pakkies op die tonnel aankom en niks na die bestemming uitgaan nie, is deurgee of NAT die verdagte. Wanneer glad niks aankom nie, is die sessie op maar die kliënt stuur nie, en die kliënt se roetetabel is die plek om te kyk.

Kontroleer die oplossing en verwyder wat nie gehelp het nie

Herhaal ná ’n goedgekeurde regstelling die presiese toets wat misluk het en teken die resultaat teen dieselfde profiel en toestel aan. Verwyder dan enige tydelike uitsondering wat nie die uitkoms verander het nie, want ongebruikte uitsonderings hoop op en elkeen is ’n besluit wat niemand onthou het nie. Hou wat oorbly smal: een bestemming, een poort, een rigting, een eienaar.

Voer dieselfde drie opdragte weer uit en vergelyk hulle met die uitsette wat jy voor die verandering gestoor het.

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

Wanneer die vergelykingsnetwerk werk, die oorspronklike netwerk steeds misluk en die gebeurtenisse leeg bly, is die oorblywende verdagte die pad eerder as die gasheer. Gee dit aan die netwerkeienaar as ’n spesifieke stelling, met albei vergelykingsresultate aangeheg. Dit is ’n beter plek om te stop as ’n gedeaktiveerde firewall-profiel.