Blokuje firewall VPN? Kontrola krok za krokom

Jeden časový limit VPN dokazuje, že neprišla žiadna použiteľná odpoveď, a nič nedokazuje o príčine. Profil môže uvádzať nesprávny port, server môže byť mimo prevádzky alebo požiadavka môže doraziť bez fungujúcej spiatočnej cesty. Každý z týchto prípadov zanecháva inú stopu a práve stopa hovorí, ktorého pravidla sa treba dotknúť. Prejdite štyri etapy nižšie v poradí. Zastavte sa hneď, ako jedna z nich symptóm vysvetlí.

Krok 1: potvrďte server a transport

Čítajte názov servera, transport a port z aktuálneho profilu operátora, nie z lokálnej úpravy. Port zmenený na notebooku nemôže vytvoriť poslucháča na verejnom serveri a tento nesúlad vytvára časový limit rovnaký ako blokovanie. Ak profil ponúka podporovaný alternatívny transport, poznačte ho ako záložnú možnosť, nie ako opravu. Preložte názov a porovnajte odpoveď s adresou, ktorú operátor zverejnil.

Zastaraný záznam DNS posiela klienta na hostiteľa, ktorý nikdy neodpovedal. To je ďalšia porucha napodobňujúca filter a jej vylúčenie stojí jeden dotaz.

Zapíšte obe hodnoty do tiketu. Každé ďalšie porovnanie ich používa a tiket bez nich začína vyšetrovanie odznova.

Krok 2: preukážte cestu jedným riadeným porovnaním

Nechajte zariadenie aj profil bez zmeny a skúste inú dôveryhodnú prístupovú sieť. Ak sa tam tunel zdvihne, rozdielom je pôvodná cesta alebo jej politika. Ak na pôvodnej sieti funguje druhé schválené zariadenie, rozdielom je prvé zariadenie. Jedno z týchto dvoch porovnaní je takmer vždy rozhodujúce.

Najprv dokončite akékoľvek legitímne sieťové prihlásenie, pretože captive portál vyzerá ako blokovanie, kým nie je dokončený.

Testujte port, ktorý skutočne používate, a výsledok TCP berte ako informáciu len o TCP.

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

Úspešný TCP handshake na porte 443 znamená, že tam odpovedal poslucháč. Nič nehovorí o UDP poslucháčovi na 51820 ani o tom, či sa rokovanie dokončilo.

Krok 3: prečítajte si bezpečnostné udalosti pre okamih zlyhania

Udalosti firewallu sú najsilnejší dostupný dôkaz a nesú výhradu, ktorú treba uviesť najprv. Protokolovanie je v mnohých predvolených profiloch vypnuté, preto overte, či príslušný profil zaznamenáva zahadzovanie, skôr než prázdny protokol prečítate ako dôkaz neviny. Keď je protokolovanie zapnuté, udalosť uvádza pravidlo, smer a adresy, čo je presne to, čo zmena pravidla potrebuje. Pravidlá aplikácií a pravidlá portov sú samostatné objekty a spravovaná politika môže prepísať lokálne nastavenie. Overte, ktorého klienta a ktorú službu pravidlo skutočne pokrýva.

Zbierajte stav profilu a nedávne udalosti zo stroja, ktorý zlyhal, nie zo susedného hostiteľa.

Porovnajte čas udalosti s časom svojho testovacieho pokusu, pretože zhodný názov pravidla s inou časovou pečiatkou je náhoda.

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

Na serveri, ktorý spravujete, sa pýtajte, či požiadavka vôbec dorazila k poslucháčovi. Dorazivší paket bez odpovede je problém presmerovania alebo spiatočnej trasy. Požiadavka, ktorá sa nikdy neobjaví, je problém filtrovania alebo adresovania.

Krok 4: otestujte presmerovanie po zdvihnutí tunela

Firewall môže reláciu povoliť a napriek tomu odmietnuť všetko, kam sa relácia chce dostať. Sysctl presmerovania, pravidlá NAT a spiatočné trasy stoja až po autentifikácii a široká výnimka pre port VPN neopraví ani jednu z nich. Otestujte jeden interný cieľ a jeden internetový cieľ oddelene, pretože zvyčajne zlyhávajú z rôznych dôvodov. Ak interné názvy zlyhávajú, ale adresy fungujú, pozrite sa na pretláčaný DNS pred akýmkoľvek pravidlom.

Spustite tri kontroly nižšie na serveri, kým je klient pripojený a pokúša sa o zlyhávajúcu požiadavku.

Počítadlá na rozhraní tunela sú to podstatné, pretože ukazujú, či pakety vošli a či niečo vyšlo.

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

Keď pakety dorazia na tunel a nič neodchádza k cieľu, podozrivým je presmerovanie alebo NAT. Keď nedorazí nič, relácia je zdvihnutá, ale klient neodosiela, a miestom na pohľad je smerovacia tabuľka klienta.

Overte opravu a odstráňte to, čo nepomohlo

Po schválenej oprave zopakujte presne ten test, ktorý zlyhal, a zaznamenajte výsledok voči rovnakému profilu a zariadeniu. Potom odstráňte každú dočasnú výnimku, ktorá nezmenila výsledok, pretože nevyužité výnimky sa hromadia a každá je rozhodnutie, ktoré si nikto nepamätá. Čo zostane, držte úzke: jeden cieľ, jeden port, jeden smer, jeden zodpovedný.

Spustite znova tie isté tri príkazy a porovnajte ich s výstupmi, ktoré ste uložili pred zmenou.

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

Keď porovnávacia sieť funguje, pôvodná sieť stále zlyháva a udalosti zostávajú prázdne, zostávajúcim podozrivým je cesta, nie hostiteľ. Odovzdajte to vlastníkovi siete ako konkrétne tvrdenie s priloženými oboma výsledkami porovnania. To je lepšie miesto na zastavenie než vypnutý profil firewallu.