VPN je pripojená, ale firewall stále blokuje: ako zistiť, čo je príčinou

Tunel beží a jeden port napriek tomu zlyháva. Prečítajte si cestu, potom politiku v každej vrstve a zmeňte najužšie pravidlo namiesto vypnutia jednej z dvoch kontrol.

Klient hlási pripojenie, zdroj stále odmieta a zvyčajný ďalší krok je niečo vypnúť. Obe kontroly v tej vete robia rôznu prácu: VPN stavia cestu pre pokrytú prevádzku a firewall rozhoduje pri každom spojení, či prevádzka môže prejsť. Fungujúci tunel s odmietajúcou politikou vyzerá z používateľovho miesta úplne ako pokazený tunel, takže úlohou je zistiť, ktorá vrstva odpovedá. Tu je poradie, ktorým idem, s čítaním, ktoré vám povie, aby ste prestali.

Oddeľte cestu od politiky

Začnite tvarom zlyhania, pretože to je informácia zadarmo. Zahodenie paketu dáva timeout: klient to skúša znova, nič sa nevracia a príkaz visí, kým to nevzdá. Odmietnutie dáva refusal alebo reset: niečo odpovedalo a povedalo nie. Služba, ktorá nepočúva, odmieta na samotnom hostiteľovi, bez akéhokoľvek firewallu.

Tie tri výsledky ukazujú na rôzne vrstvy. Timeout znamená, že niekde politika ticho zahadzuje, alebo trasa nikdy neopustí stroj. Odmietnuté znamená, že ste sa dostali k hostiteľovi a jeho stack alebo jeho hostiteľský firewall to odmietol. Úplné ticho, so zapnutým rozhraním tunela a bez trasy k cieľu, znamená, že cesta je nesprávna a žiadne pravidlo firewallu to nespraví.

Prečítajte cestu na jeden prechod

Potvrďte, že tunel pokrýva cieľ, skôr než sa pozriete na jediné pravidlo. Rozdelený tunel, ktorý nesie len kancelársku podsiev, nepošle požiadavku do iného rozsahu, a zlyhanie potom vyzerá ako blokovanie firewallom, ktorým nie je:

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

Výstup trasy pomenúva rozhranie, ktorým paket odíde, a zdrojovú adresu, ktorú ponesie. Ak je tým rozhraním vaša fyzická sieťová karta a nie tunel, problém je v smerovaní alebo v povolených rozsahoch tunela a patrí ku konfigurácii VPN, nie k firewallu.

Jedna pasca špecifická pre VPN si zaslúži vlastnú kontrolu. Vo WireGuarde je AllowedIPs protivníka zároveň trasa aj kryptografický filter: paket, ktorého zdrojová adresa nezodpovedá povolenej množine protivníka, sa zahodí skôr, než sa pozrie akékoľvek pravidlo firewallu. Preto môže perfektne správny hostiteľský firewall stáť za tichým zahodením, ktoré vyzerá ako politika, a oprava je riadok konfigurácie kľúča, nie pravidlo.

Prečítajte politiku vo vrstve, ktorá odpovedá

Keď je cesta správna, prejdite politiku od hostiteľa von a sledujte jedinú vrstvu, ktorej počítadlá sa hýbu:

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

Počúvajúci socket odpovedá na inú otázku než pravidlá. Ak na porte nič nepočúva, jadro spojenie odmietne a žiadne vstupné pravidlo nie je podstatné. Ak socket existuje a spojenie od vzdialeného klienta vyprší, zahodenie sa deje niekde na ceste a počítadlá pravidiel povedia, či sa deje tu.

Zapnite logovanie pre profil alebo reťazec, ktorý podozrievate, namiesto hádania zvonku. Jedno zaznamenané zahodenie, ktoré pomenuje zdroj, cieľ a port, určí vrstvu aj pravidlo a tiež dokáže, že paket dorazil, čo žiadne testovanie na strane klienta nepreukáže.

Prečítajte rozhodnutie brány, keď tam tunel končí

Na bráne site-to-site alebo vzdialeného prístupu VPN autentifikuje používateľa a politika autorizuje zdroj, a to sú oddelené oprávnenia. Používateľ vpustený do tunela nie je automaticky vpustený na každého interného hostiteľa a odmietnutie často prichádza z pravidla preposielania, pričom samotný tunel je zdravý. Rovnaké oddelenie je v IPsec, kde sa bezpečnostná politika, ktorá vyberá prevádzku, líši od filtra, ktorý ju prepúšťa, a preto sú obe dokumentované ako rôzne mechanizmy v RFC 4301.

Skontrolujte spiatočnú cestu rovnako starostlivo ako odchádzajúcu. Stavové filtrovanie musí vidieť odpoveď, takže asymetrické smerovanie tunelom v jednom smere a okolo neho v druhom dáva zahodenia, ktoré vyzerajú náhodne a opakujú sa len u niektorých klientov. Ak prevádzka dorazí na bránu a zastaví sa, prečítajte pravidlo preposielania a spiatočnú trasu spoločne, skôr než čokoľvek rozšírite.

Brána je aj miesto, kde pravidlo NAT alebo maskovania môže skryť skutočný zdroj. Ak interní hostitelia vidia adresu brány namiesto klienta, ich pravidlá hostiteľského firewallu, ktoré majú zodpovedať fondu klientov, nebudú nikdy zodpovedať, a oprava patrí bráne, nie každému serveru.

Zmeňte najužšiu vrstvu a potom overte

Odolajte širokej oprave. Vypnutie hostiteľského firewallu, pridanie pravidla, ktoré povolí všetko, alebo vnútenie každého rozhrania do dôveryhodného profilu zakaždým odstráni kontrolu, ktorá robila svoju prácu, a zmena prežije incident. Pravidlo obmedzené na zdrojový rozsah a dotknutý port sa ľahšie kontroluje, ľahšie odstraňuje a zvyšok politiky stroja zostane nedotknutý.

Overte tým istým testom, ktorý zlyhal, z toho istého klienta, a potom ešte raz po opätovnom pripojení, pretože pravidlo, ktoré platilo pred novým vyjednaním tunela, po ňom môže prestať platiť:

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

Než to uzavriete:

  • Trasa k cieľu vychádza rozhraním tunela a zdrojová adresa zodpovedá tomu, čo politika očakáva.
  • Na porte niečo počúva a odmietnutie alebo timeout sa pripisuje pomenovanému pravidlu, nie predpokladu.
  • Brána preposiela v oboch smeroch a cieľ vidí zdroj, pre ktorý boli vaše pravidlá napísané.
  • Žiadna kontrola nebola vypnutá, aby test prešiel, a zmena, ktorú ste urobili, pomenúva jeden zdrojový rozsah a jeden port.

Súvisiace články