Blochează firewall-ul VPN-ul? O verificare pas cu pas

Un singur timeout VPN dovedește că nu a sosit niciun răspuns utilizabil și nu dovedește nimic despre cauză. Profilul poate indica portul greșit, serverul poate fi oprit sau cererea poate sosi fără o cale de întoarcere funcțională. Fiecare dintre acestea lasă o urmă diferită, iar urma este cea care vă spune ce regulă trebuie atinsă. Parcurgeți cele patru etape de mai jos în ordine. Opriți-vă imediat ce una dintre ele explică simptomul.

Etapa 1: confirmați serverul și transportul

Citiți numele serverului, transportul și portul din profilul actual al operatorului și nu dintr-o modificare locală. Un port schimbat pe laptop nu poate crea un listener pe un server public, iar această nepotrivire produce un timeout identic cu o blocare. Dacă profilul oferă un transport alternativ acceptat, notați-l ca soluție de rezervă și nu ca remediere. Rezolvați numele și comparați răspunsul cu adresa pe care operatorul a publicat-o.

O înregistrare DNS veche trimite clientul către un host care nu a răspuns niciodată. Este o altă defecțiune care imită un filtru, iar eliminarea ei costă o singură interogare.

Scrieți ambele valori în tichet. Fiecare comparație ulterioară le folosește, iar un tichet fără ele reîncepe investigația.

Etapa 2: dovediți calea cu o singură comparație controlată

Lăsați dispozitivul și profilul neschimbate și încercați o altă rețea de acces de încredere. Dacă tunelul urcă acolo, diferența este calea originală sau politica ei. Dacă un al doilea dispozitiv aprobat funcționează în rețeaua originală, diferența este primul dispozitiv. Una dintre aceste două comparații este aproape întotdeauna decisivă.

Finalizați mai întâi orice autentificare de rețea legitimă, deoarece un portal captiv arată ca o blocare până când este finalizat.

Testați portul pe care îl folosiți efectiv și tratați un rezultat TCP ca informație doar despre TCP.

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

Un handshake TCP reușit pe portul 443 spune că acolo a răspuns un listener. Nu spune nimic despre un listener UDP pe 51820 și nici dacă negocierea s-a încheiat.

Etapa 3: citiți evenimentele de securitate pentru momentul defecțiunii

Evenimentele firewall sunt cea mai puternică dovadă disponibilă și au o rezervă care merită spusă mai întâi. Jurnalizarea este dezactivată în multe profiluri implicite, așa că verificați dacă profilul respectiv înregistrează respingeri înainte de a citi un jurnal gol ca dovadă a nevinovăției. Când jurnalizarea este activă, evenimentul numește regula, direcția și adresele, exact ce are nevoie o modificare de regulă. Regulile de aplicație și regulile de port sunt obiecte separate, iar politica gestionată poate suprascrie o setare locală. Confirmați ce client și ce serviciu acoperă de fapt o regulă.

Colectați starea profilului și evenimentele recente de pe mașina care a eșuat, nu de pe un host vecin.

Citiți ora evenimentului față de ora încercării de test, deoarece un nume de regulă potrivit cu un marcaj temporal diferit este o coincidență.

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

Pe un server pe care îl administrați, întrebați dacă cererea a ajuns măcar la listener. Un pachet care sosește fără răspuns este o problemă de redirecționare sau de rută de întoarcere. O cerere care nu apare niciodată este o problemă de filtrare sau de adresare.

Etapa 4: testați redirecționarea după ce tunelul este ridicat

Un firewall poate permite sesiunea și totuși poate refuza tot ce sesiunea vrea să atingă. Sysctl-urile de redirecționare, regulile NAT și rutele de întoarcere stau toate după autentificare, iar o excepție largă pentru portul VPN nu repară niciuna dintre ele. Testați separat o destinație internă și o destinație de internet, deoarece de obicei eșuează din motive diferite. Dacă numele interne eșuează dar adresele funcționează, priviți DNS-ul împins înaintea oricărei reguli.

Rulați cele trei verificări de mai jos pe server în timp ce un client este conectat și încearcă cererea care eșuează.

Contoarele interfeței tunelului sunt punctul cheie, deoarece arată dacă pachetele au intrat și dacă a ieșit ceva.

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

Când pachetele ajung pe tunel și nimic nu iese spre destinație, suspectul este redirecționarea sau NAT-ul. Când nu ajunge nimic, sesiunea este ridicată dar clientul nu trimite, iar locul de privit este tabela de rute a clientului.

Verificați remedierea și eliminați ce nu a ajutat

După o corecție aprobată, repetați exact testul care a eșuat și înregistrați rezultatul față de același profil și dispozitiv. Apoi eliminați orice excepție temporară care nu a schimbat rezultatul, deoarece excepțiile neutilizate se acumulează și fiecare este o decizie pe care nimeni nu-și amintește că a luat-o. Păstrați îngust ce rămâne: o destinație, un port, o direcție, un responsabil.

Rulați din nou aceleași trei comenzi și comparați-le cu ieșirile pe care le-ați salvat înainte de modificare.

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

Când rețeaua de comparație funcționează, rețeaua originală încă eșuează și evenimentele rămân goale, suspectul rămas este calea și nu hostul. Predați asta responsabilului de rețea ca o afirmație concretă, cu ambele rezultate ale comparației atașate. Este un loc mai bun de oprire decât un profil de firewall dezactivat.