Pravidlo naslouchajícího portu ve firewalld versus politika přesměrování: co dělá které

VPN, které se připojí, ale nikam se nedostane, se obvykle popisuje jako problém brány firewall a řešení, ke kterému lidé sahají, je dát rozhraní tunelu do důvěryhodné zóny. To funguje v tom smyslu, že provoz začne proudit, ale propustí také mnohem víc než zamýšlenou službu. Obě zúčastněné politiky jsou různé: jedna propouští vnější transport k naslouchajícímu socketu, druhá opravňuje dešifrovaný provoz k dosažení konkrétního prostředku. Právě to, že se s nimi zachází jako s jedním nastavením, mění úzké povolení na široké. Obě se rozhodují na různých místech, a proto je ta chyba tak snadná.

Dvě politiky, jeden tunel

Vnější politika odpovídá na jednoduchou otázku: smí paket z tohoto zdroje dosáhnout UDP 1194 na tomto hostiteli? Vnitřní politika odpovídá na jinou: smí ověřený klient za tímto tunelem dosáhnout tohoto cíle, tímto protokolem, na tomto portu? První je o socketu, druhá o cestě, a firewalld je modeluje různými objekty, protože se rozhodují v různých bodech. Jedna je vlastnost socketu na tomto hostiteli, druhá vlastnost cesty skrz něj.

Praktickým důsledkem je, že funkční tunel o druhé politice nic neříká a správná druhá politika nečiní první zbytečnou.

Propustěte skutečný vnější naslouchající port

Začněte tím, že prozkoumáte, co je už přiřazeno, místo abyste předpokládali. Přečtěte si aktivní zóny, vypište zónu, která skutečně nese příchozí provoz, a zkontrolujte nainstalovanou definici služby, protože název služby popisuje sadu portů a neříká nic o tom, zda s ním naslouchající port tohoto serveru souhlasí.

firewall-cmd --get-active-zones
firewall-cmd --zone=public --list-all
firewall-cmd --info-service=openvpn

Pokud je naslouchající port skutečně UDP 1194 v této zóně, otevřete konkrétně tento port a transport a poté po otestování nastavte stejné konkrétní pravidlo trvale. Zkontrolujte také přiřazení podle zdroje, protože zóna vázaná na rozsah zdrojů může provoz zachytit dřív, než ho zóna rozhraní vůbec uvidí.

Autorizujte dešifrovaný cíl odděleně

Spojení se službou běžící přímo na serveru VPN je politika místního vstupu. Spojení přesměrované na jiného hostitele v LAN potřebuje politiku přesměrování, přesměrování povolené v jádru a zpětnou trasu — to jsou tři oddělené požadavky, které lidé běžně slévají do jednoho. Moderní objekty politik firewalld popisují směrovaný provoz mezi vstupní a výstupní zónou a právě tam je správné místo vyjádřit, které zdroje VPN smějí dosáhnout kterých soukromých služeb.

Povolené zdroje definujte výslovně a všechno ostatní nechte propadnout do zamítnutí. Povolení pro vnější službu není tou politikou, ať už rozvržení zón vypadá jakkoli.

Proč je důvěra v rozhraní špatná zkratka

Umístění rozhraní tunelu do zóny, jejíž cíl přijímá všechno, propustí všechen dešifrovaný provoz ke každé službě, kterou hostitel vystavuje, včetně těch, které jste neprošli. Přecílení důvěryhodné zóny na omezující na běžícím stroji je horší, protože jiná rozhraní a rozsahy zdrojů už mohou na jejím významu záviset a při úpravě změní chování. Potřebujete-li úzkou politiku, vytvořte ji; nepřetvářejte sdílenou zónu.

Také udržujte přiřazení zóny tunelu stabilní přes jakoukoli komponentu, která tu konfiguraci vlastní. Ztráta přiřazení při restartu vytváří selhání, které vypadá jako problém pravidla firewallu a ve skutečnosti je problémem persistence.

Ověřte tři věci, včetně jednoho zamítnutí

Otestujte vnější spojení zvenčí, otestujte jednu autorizovanou vnitřní službu z připojeného klienta a otestujte jednu službu, která má zůstat nedostupná. Třetí test je ten, který odlišuje politiku od vedlejšího efektu, a právě ten lidé vynechávají, protože všechno vypadá, že funguje. Pokud zamítnutá služba odpovídá, propustili jste zónu, ne službu.

Zapište zónu, port, transport a objekt politiky do poznámek serveru. Jinak příští změna na tomto hostiteli začne od stejného předpokladu.