Přidali jste adresu VPN na whitelist a přesto je blokovaná? Vysledujte ji

Přidání adresy, kterou zobrazuje aplikace VPN, na whitelist zřídka opraví blokovaný port a paket vysvětluje proč. Firewall vaše pravidlo neignoruje; vyhodnocuje zdrojovou adresu, kterou na obrazovce klienta nic nezobrazuje. Dokud cíl tuto hodnotu nenahlásí, je každá úprava pravidla jen domněnka.

Začněte požadavkem, který do služby dorazí. Adresa tunelu, výstupní adresa i jakýkoli překlad mezi nimi zůstávají hypotézami, dokud cíl jednu z nich nepotvrdí.

Adresa v aplikaci není ta, která dorazí

Spojení VPN nese nejméně čtyři adresy, které stojí za to pojmenovat zvlášť: koncový bod serveru, vnitřní adresu tunelu přidělenou vašemu klientovi, místní adresu Wi-Fi nebo Ethernet a veřejnou adresu, kterou web vidí poté, co provoz opustí poskytovatele. Okno klienta může zobrazovat jen druhou z nich. Pojmenujte všechny čtyři, než pojmenujete pravidlo. Při rozděleném tunelování mohou požadavky na veřejný cíl tunel úplně obejít, takže selhávající relace není ta, o které si uživatel myslí, že ji zahájil.

Určete, kterou z těch čtyř má pravidlo povolit, a poté ji ověřte z druhé strany. Pokud je požadavek skutečně kancelářská adresa, podmínkou je trasa plus výstupní uspořádání onoho pracoviště a spojení označené Office VPN samo o sobě neposkytuje ani jedno.

Proveďte jeden požadavek až k jeho filtrační hranici

Potvrďte cílovou adresu a port, které klient používá, a pak ověřte, že tento cíl sleduje cestu, kterou předpokládáte. Publikovaný port kontejneru, reverzní proxy nebo přesměrování portu mohou rozhodnutí přesunout na hostitele, který jste nikdy neupravovali. Každý z těchto kroků může mít vlastní politiku. Nejprve zjistit cestu vás ušetří opravování pravidla, ke kterému se žádný paket nedostane.

Na autorizovaném hostiteli Linuxu si před změnou přečtěte živá pravidla v pořadí. Přesměrované a kontejnerové služby často skáčou do vlastního řetězce, proto prohlédněte cíl skoku i konečný verdikt.

iptables -vnL INPUT --line-numbers
iptables -S INPUT | head -n 40
ss -ltnp | grep -E ':(443|9443)\b'

V tiketu uveďte číslo odpovídajícího pravidla. Bez něj další čtenář nepozná, která úprava změnila výsledek. Číslo pravidla bez časového razítka je stále nejednoznačné.

Ověřte cestu jediným omezeným zachycením

Jeden neškodný požadavek a jedno úzké zachycení vyřeší otázku, která se stále vrací. Filtrujte podle cílového portu a zkoumaného hostitele, omezte počet paketů a zachycení ukončete, jakmile požadavek skončí.

tcpdump -ni any 'tcp dst port 9443' -c 20

Porovnejte tři hodnoty vedle sebe: zdroj v zachycení, zdroj, který uvádí odpovídající pravidlo, a odmítnutí, které aplikace zaznamenala. Všechny se mohou lišit a jen první vysvětluje zahození rozhodnuté pravidlem IP. Přeposlaná hlavička HTTP patří vrstvě proxy, takže záznam citující tuto hlavičku nepopisuje zdroj, který firewall vyhodnotil.

Čtěte pořadí řetězce, ne jen pravidlo

Reference iptables dokumentuje uspořádaný průchod, a proto povolení umístěné pod odpovídajícím koncovým odmítnutím paket nikdy nezachrání. Dříve přijaté spojení se také může chovat jinak než nové, takže starý úspěch o novém pravidle nic neříká. Než usoudíte, že je povolení špatné, najděte odmítnutí nebo zahození nad svým povolením. Počítadla u každého pravidla také řeknou, které pravidlo paket vidělo.

Smazání pravidla, abyste viděli, co se stane, je změna, ne pozorování. Přečtěte počítadla, poznamenejte číslo pravidla a původní politiku uložte do záznamu změn. Pokud je test nevyhnutelný, spusťte ho na kopii řetězce.

Změňte pravidlo, které ovládá jeho vlastník

Aktualizujte pouze zamýšlenou politiku zdroje a služby, prostřednictvím toho, kdo ji vlastní. Sdílený přeložený výstup může zastupovat mnoho uživatelů najednou, takže povolení této adresy nikoho neověří a oprávnění aplikace za ním zůstávají tam, kde jsou.

Když se adresa stále mění, trvalou odpovědí je stabilní výstup nebo ověřený kanál, ne delší seznam výjimek. Zaznamenejte pozorovaný zdroj, cílový port a číslo pravidla.