Blokuje firewall VPN? Kontrola krok za krokem

Jedno vypršení časového limitu VPN dokazuje, že nedorazila použitelná odpověď, a nic nedokazuje o příčině. Profil může uvádět špatný port, server může být mimo provoz nebo požadavek může dorazit bez fungující zpětné cesty. Každý z těchto případů zanechává jinou stopu a právě stopa vám řekne, které pravidlo se dotknout. Projděte čtyři fáze níže v pořadí. Zastavte se, jakmile jedna z nich symptom vysvětlí.

Krok 1: potvrďte server a transport

Čtěte název serveru, transport a port z aktuálního profilu operátora, ne z místní úpravy. Port změněný na vašem notebooku nemůže vytvořit naslouchající proces na veřejném serveru a tento nesoulad vytváří vypršení časového limitu stejné jako blokování. Pokud profil nabízí podporovaný alternativní transport, poznamenejte jej jako záložní variantu, nikoli jako opravu. Přeložte název a porovnejte odpověď s adresou, kterou operátor zveřejnil.

Zastaralý záznam DNS posílá klienta na hostitele, který nikdy neodpověděl. To je další závada, která napodobuje filtr, a její vyloučení stojí jeden dotaz.

Zapište obě hodnoty do tiketu. Každé další srovnání je používá a tiket bez nich začíná vyšetřování znovu.

Krok 2: prokažte cestu jedním řízeným srovnáním

Ponechte zařízení i profil beze změny a zkuste jinou důvěryhodnou přístupovou síť. Pokud se tam tunel zvedne, rozdílem je původní cesta nebo její politika. Pokud na původní síti funguje druhé schválené zařízení, rozdílem je první zařízení. Jedno z těchto dvou srovnání je téměř vždy rozhodující.

Nejprve dokončete jakékoli legitimní přihlášení k síti, protože captive portál vypadá jako blokování, dokud není dokončen.

Testujte port, který skutečně používáte, a výsledek TCP berte jako informaci pouze o TCP.

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

Úspěšný TCP handshake na portu 443 říká, že tam odpověděl naslouchající proces. Nic neříká o UDP naslouchači na 51820 ani o tom, zda vyjednávání skončilo.

Krok 3: přečtěte si bezpečnostní události pro okamžik selhání

Události firewallu jsou nejsilnější dostupný důkaz a nesou výhradu, kterou je vhodné uvést nejprve. Protokolování je v mnoha výchozích profilech vypnuté, proto nejprve ověřte, zda příslušný profil zaznamenává zahazování, než prázdný protokol přečtete jako důkaz neviny. Když je protokolování zapnuté, událost uvádí pravidlo, směr a adresy, což je přesně to, co změna pravidla potřebuje. Pravidla aplikací a pravidla portů jsou samostatné objekty a spravovaná politika může místní nastavení přepsat. Ověřte, který klient a kterou službu pravidlo skutečně pokrývá.

Sbírejte stav profilu a nedávné události ze stroje, který selhal, ne ze sousedního hostitele.

Porovnejte čas události s časem svého testovacího pokusu, protože shodný název pravidla s jiným časovým razítkem 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 serveru, který spravujete, se ptejte, zda požadavek vůbec dorazil k naslouchajícímu procesu. Dorazivší paket bez odpovědi je problém přesměrování nebo zpětné trasy. Požadavek, který se nikdy neobjeví, je problém filtrování nebo adresace.

Krok 4: otestujte přesměrování po zvednutí tunelu

Firewall může relaci povolit a přesto odmítnout vše, kam se relace chce dostat. Sysctl pro přesměrování, pravidla NAT a zpětné trasy stojí až po autentizaci a široká výjimka pro port VPN neopraví ani jedno z nich. Otestujte jeden interní cíl a jeden internetový cíl odděleně, protože obvykle selhávají z různých důvodů. Pokud interní názvy selhávají, ale adresy fungují, podívejte se na zatlačený DNS dříve než na jakékoli pravidlo.

Spusťte tři kontroly níže na serveru, zatímco je klient připojen a pokouší se o selhávající požadavek.

Počítadla na rozhraní tunelu jsou to podstatné, protože ukazují, zda pakety vešly a zda něco vyšlo.

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

Když pakety na tunel dorazí a k cíli nic neodejde, podezřelým je přesměrování nebo NAT. Když nedorazí nic, relace je zvednutá, ale klient neodesílá, a místem, kam se podívat, je routovací tabulka klienta.

Ověřte opravu a odstraňte to, co nepomohlo

Po schválené opravě zopakujte přesně ten test, který selhal, a zaznamenejte výsledek proti stejnému profilu a zařízení. Poté odstraňte každou dočasnou výjimku, která výsledek nezměnila, protože nevyužité výjimky se hromadí a každá je rozhodnutí, které si nikdo nepamatuje. Co zůstane, držte úzké: jeden cíl, jeden port, jeden směr, jeden vlastník.

Spusťte znovu stejné tři příkazy a porovnejte je s výstupy, které jste uložili před změnou.

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

Když srovnávací síť funguje, původní síť stále selhává a události zůstávají prázdné, zbývajícím podezřelým je cesta, ne hostitel. Předejte to vlastníkovi sítě jako konkrétní tvrzení s přiloženými oběma výsledky srovnání. To je lepší místo pro zastavení než vypnutý profil firewallu.