Publikování portů v Dockeru a zdroje VPN: dvě shody, které míjíte

Pravidlo říká povolte adresu VPN serveru k publikované službě, a spojení přesto padá. Takový výsledek je běžný a není to chyba Dockeru. Dvě samostatné shody jsou špatně: zdroj, který jste napsali, nemusí být zdroj, který hostitel přijímá, a port, který jste napsali, nemusí být port, který vidí filtr. Oprava obou vyžaduje pohled na cestu paketu, ne na schéma služby.

Mýtus: povolte VPN server a je hotovo

Směrovaná VPN může zachovat adresu klientského tunelu až k hostiteli Dockeru. Brána, která provádí překlad zdroje, může tuto adresu nahradit svou vlastní. Obě řešení jsou legitimní a pro stejnou akci uživatele dávají různé zdroje.

Takže fráze IP adresa VPN serveru popisuje předpoklad, nikoli pozorování. Dokud nevíte, které z obou řešení je před vámi, je pravidlo odhad.

Zdroj: klientský fond, nebo přeložená brána

Zkontrolujte čtyři věci v pořadí. Za prvé, fond klientských adres, například 10.90.0.0/24. Za druhé, zda brána tento fond překládá, než dorazí k hostiteli. Za třetí, jaký zdroj hostitel skutečně pozoruje u jednoho nového spojení. Za čtvrté, zda ověřování v aplikaci rozlišuje jednotlivé uživatele, protože sdílená přeložená adresa to nedokáže.

Pokud se fond zachová, pravidlo odpovídající jen veřejné adrese brány mine každého klienta. Pokud brána překládá záměrně, povolení přeložené adresy pustí každého uživatele za ní, což může být přijatelné pro službu s vlastním přihlášením a nepřijatelné pro cokoli jiného.

Port: DNAT mění číslo, které porovnáváte

U běžného publikování přes most Linuxu s Docker iptables se mapování hostitele z 8443 na port kontejneru 443 přeloží dřív, než se spustí filtr předávání. Paket dorazí k filtru s cílovým portem 443. Pravidlo, které v tom okamžiku odpovídá 8443, se nikdy neuplatní, i když 8443 je to, co klient napsal.

Publikovaný port stále existuje ve sledování spojení, proto lze původní cíl porovnat tam, když ho skutečně potřebujete.

Rozhodněte, které číslo vyjadřuje záměr. Porovnávejte port kontejneru po DNAT, když pravidlo chrání službu uvnitř kontejneru. Porovnávejte původní cíl s volbou conntrack, když pravidlo musí popsat, co klient požadoval, a přijměte vyšší náklady na porovnání i péči o pořadí pravidel, které s tím přicházejí.

Řetěz: DOCKER-USER, ne INPUT

Průvodce Dockeru k iptables umisťuje uživatelskou politiku předávání do řetězu DOCKER-USER, který se vyhodnocuje před vlastními pravidly předávání Dockeru. Pravidlo zkopírované ze služby hostitele do řetězu INPUT filtruje provoz adresovaný hostiteli, ne provoz předávaný do kontejneru. Tato chyba vytvoří pravidlo, které vypadá správně a na cestu kontejneru nemá vliv.

Držte rozsah zdroje, efektivní cílový port, protokol a vstupní rozhraní společně ve stejném pravidle. Povolení jen podle zdroje pro každý předávaný cíl je širší než povolení jedné publikované služby.

Ověřte novými spojeními

Otestujte oba směry novými spojeními: jeden povolený klient VPN a jeden zdroj, který má zůstat zakázaný. Existující stav spojení může udržet relaci živou i po změně politiky, takže staré spojení o novém pravidle nic nedokazuje. Potom zkontrolujte cestu odpovědi, protože kontejner se stále musí směrovat zpět ke zdroji, který vidí.

Pořadí řetězů a chování překladu portů za těmito kontrolami dokumentuje průvodce iptables v Dockeru. Přečtěte si ho před kopírováním receptu a ověřte, který backend nainstalovaný Docker používá, protože backend nftables integruje politiku jinak.