VPN je připojená, ale firewall pořád blokuje: jak zjistit, co je příčinou

Tunel běží a jeden port přesto selhává. Přečtěte si cestu, pak politiku v každé vrstvě a změňte nejužší pravidlo, místo abyste vypnuli jednu z obou kontrol.

Klient hlásí připojeno, zdroj stále odmítá a obvyklý další krok je něco vypnout. Obě kontroly v té větě dělají různou práci: VPN staví cestu pro pokrytý provoz a firewall rozhoduje u každého spojení, zda provoz může projít. Funkční tunel s odmítající politikou vypadá z uživatelova místa úplně jako rozbitý tunel, takže úkolem je zjistit, která vrstva odpovídá. Tady je pořadí, kterým jdu, s čtením, které vám řekne, abyste přestali.

Oddělte cestu od politiky

Začněte tvarem selhání, protože to je informace zdarma. Zahození paketu dává timeout: klient to zkouší znovu, nic se nevrací a příkaz visí, dokud to nevzdá. Odmítnutí dává refusal nebo reset: něco odpovědělo a řeklo ne. Služba, která neposlouchá, odmítá na samotném hostiteli, bez jakéhokoli firewallu.

Ty tři výsledky ukazují na různé vrstvy. Timeout znamená, že někde politika tiše zahazuje, nebo trasa nikdy neopustí stroj. Odmítnuto znamená, že jste se dostali k hostiteli a jeho stack nebo jeho hostitelský firewall to odmítl. Naprosté ticho, se zapnutým rozhraním tunelu a bez trasy k cíli, znamená, že cesta je špatná a žádné pravidlo firewallu to nespraví.

Přečtěte cestu na jeden průchod

Potvrďte, že tunel pokrývá cíl, než se podíváte na jediné pravidlo. Rozdělený tunel, který nese jen kancelářskou podsíť, nepošle požadavek do jiného rozsahu, a selhání pak vypadá jako blokování firewallem, kterým není:

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

Výstup trasy pojmenuje rozhraní, kterým paket odejde, a zdrojovou adresu, kterou ponese. Pokud je tím rozhraním vaše fyzická síťová karta a ne tunel, problém je v routování nebo v povolených rozsazích tunelu a patří ke konfiguraci VPN, ne k firewallu.

Jedna past specifická pro VPN si zaslouží vlastní kontrolu. Ve WireGuardu je AllowedIPs protějšku zároveň trasa i kryptografický filtr: paket, jehož zdrojová adresa neodpovídá povolené množině protějšku, se zahodí dřív, než se prozkoumá jakékoli pravidlo firewallu. Proto může perfektně správný hostitelský firewall stát za tichým zahozením, které vypadá jako politika, a oprava je řádek konfigurace klíče, ne pravidlo.

Přečtěte politiku ve vrstvě, která odpovídá

Jakmile je cesta správná, projděte politiku od hostitele ven a sledujte jedinou vrstvu, jejíž čítače se hýbou:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

Naslouchající socket odpovídá na jinou otázku než pravidla. Pokud na portu nic neposlouchá, spojení odmítne jádro a žádné vstupní pravidlo není podstatné. Pokud socket existuje a spojení od vzdáleného klienta vyprší, zahození se děje někde na cestě a čítače pravidel řeknou, zda tady.

Zapněte logování pro profil nebo řetěz, který podezříváte, místo hádání zvenku. Jedno zaznamenané zahození, které pojmenuje zdroj, cíl a port, určí vrstvu i pravidlo a také dokáže, že paket dorazil, což žádné testování na straně klienta neprokáže.

Přečtěte rozhodnutí brány, když tam tunel končí

Na bráně site-to-site nebo vzdáleného přístupu VPN autentizuje uživatele a politika autorizuje zdroj, a to jsou oddělená oprávnění. Uživatel vpuštěný do tunelu není automaticky vpuštěný na každý interní hostitel a odmítnutí často přichází z pravidla předávání, zatímco tunel sám je zdravý. Stejné oddělení je v IPsecu, kde se bezpečnostní politika, která vybírá provoz, liší od filtru, který ho propouští, a proto jsou obojí dokumentovány jako různé mechanismy v RFC 4301.

Zkontrolujte zpáteční cestu stejně pečlivě jako odchozí. Stavové filtrování musí vidět odpověď, takže asymetrické routování tunelem v jednom směru a kolem něj v druhém dává zahození, která vypadají náhodně a opakují se jen u některých klientů. Pokud provoz dorazí na bránu a zastaví se, přečtěte pravidlo předávání a zpáteční trasu společně, než cokoli rozšíříte.

Brána je také místo, kde pravidlo NAT nebo maskování může skrýt skutečný zdroj. Pokud interní hostitelé vidí adresu brány místo klienta, jejich pravidla hostitelského firewallu, která mají odpovídat fondu klientů, nikdy nebudou odpovídat, a oprava patří bráně, ne každému serveru.

Změňte nejužší vrstvu a pak ověřte

Odolejte široké opravě. Vypnutí hostitelského firewallu, přidání pravidla, které povolí vše, nebo vnucení každého rozhraní do důvěryhodného profilu vždy odstraní kontrolu, která dělala svou práci, a změna přežije incident. Pravidlo omezené na zdrojový rozsah a dotyčný port se snáz kontroluje, snáz odstraňuje a zbytek politiky stroje zůstane nedotčen.

Ověřte stejným testem, který selhal, ze stejného klienta, a pak ještě jednou po opětovném připojení, protože pravidlo, které platilo před novým vyjednáním tunelu, po něm může přestat platit:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

Než to uzavřete:

  • Trasa k cíli vychází rozhraním tunelu a zdrojová adresa odpovídá tomu, co politika očekává.
  • Na portu něco poslouchá a odmítnutí nebo timeout se přisuzuje pojmenovanému pravidlu, ne předpokladu.
  • Brána předává v obou směrech a cíl vidí zdroj, pro který byla vaše pravidla napsaná.
  • Žádná kontrola nebyla vypnuta, aby test prošel, a změna, kterou jste udělali, pojmenovává jeden zdrojový rozsah a jeden port.

Související články