Zóny Shorewall pro dvě cesty paketů OpenVPN

Dva toky paketů procházejí bránou Shorewall, která ukončuje OpenVPN, a jen jeden z nich je šifrovaný. První je přenos klienta k posluchači VPN na rozhraní obráceném do internetu. Druhý je dešifrovaný požadavek, který opouští tunelové rozhraní směrem k serveru v kanceláři nebo službě na bráně. Zmapujte oba dřív, než začnete upravovat politiku, protože pravidlo, které splní první, nedělá pro druhý nic.

Nakreslete oba toky, než začnete upravovat politiku

Zapište toky jako řádky se zdrojem, cílem, protokolem a portem. Na vnější cestě je zdrojem veřejná adresa klienta a cílem port posluchače na bráně; Shorewall to bere jako provoz z internetu do firewallu. Na vnitřní cestě je zdrojem rozsah adres tunelu a cílem schválená služba. Oba řádky mají různé vlastníky, i když je spravuje jeden administrátor.

Řádek přidejte jen tehdy, když požadavek končí na samotné bráně, například přístup k resolveru nebo správě. Služba na hostiteli se řídí politikou vstupu hostitele, ne předávanou cestou. Právě mísením obojího úzké tunelové pravidlo nakonec odhalí administrativní rozhraní.

Přiřaďte zónu tunelu a rozsah rozhraní

Zóna cestujícího uživatele se deklaruje v /etc/shorewall/zones, tunelové rozhraní se připojuje v /etc/shorewall/interfaces a vnější spojení se popisuje v /etc/shorewall/tunnels. Přizpůsobte se syntaxi nainstalovaného vydání, protože pořadí sloupců a názvy voleb se mezi hlavními verzemi změnily. Příkladový port z návodu není důvodem povolit jiný port, než na kterém daemon skutečně naslouchá. TCP a UDP nejsou zaměnitelné jen proto, že čísla souhlasí.

Návod seskupuje rozhraní pomocí tun+. Na hostiteli s více tunely může tento zástupný znak umístit druhou VPN s jinou úrovní důvěry do stejné zóny. Prověřte rozsah proti rozhraním, která skutečně existují, a držte pojmenování v životním cyklu správce připojení, místo abyste názvy rozhraní upravovali ručně.

Historický návod obsahuje mnohem starší ukázky konfigurace OpenVPN a jeho kryptografické rady by se neměly kopírovat do současného nasazení. Vypůjčte si místo toho model zón a toků. Kryptografický základ vezměte z udržované politiky OpenVPN na bráně.

Povolte jen cestu, kterou jste klasifikovali

Široké přijetí ze zóny VPN do LAN je počáteční schéma, ne hotová politika. Zapište povolený zdroj klienta, skutečnou adresu služby, protokol a port. Pak si přečtěte pravidla nad ním a výchozí hodnotu zóny, protože úzký přírůstek neruší široké povolení, které už odpovídá. Provoz k hostiteli brány je samostatný vztah od provozu předávaného skrz něj.

Provoz mezi klienty potřebuje vlastní rozhodnutí. client-to-client v OpenVPN i routeback v Shorewallu ovlivňují, zda na sebe klienti dosáhnou, a ani jedno by se nemělo zapínat jen kvůli tomu, aby fungovala jedna aplikace v LAN. Rozhodněte, kde se izolace vynucuje, dřív než ji otestujete.

Držte zpáteční cestu ve stejném plánu. Služba nebo její router musí vědět, jak vrátit provoz do rozsahu tunelu, nebo musí návrh zdroj záměrně přeložit, a to v zamýšleném rozsahu.

Ověřte a pak dokažte obě cesty

Ověřte konfiguraci dřív, než cokoli restartujete, a nechte otevřenou nezávislou administrativní relaci pro případ, že je nová politika chybná.

shorewall check

Po čisté kontrole konfiguraci aplikujte a přečtěte si, co Shorewall načetl. Tato čtení popisují běžící politiku, ne to, co soubor zdánlivě říká.

shorewall show zones
ip route get 192.168.10.20

Otestujte jeden nový povolený požadavek a jeden záměrně odmítnutý požadavek ze stejného klienta. Úspěšný handshake OpenVPN dokazuje jen vnější výměnu; povolená služba a odmítnutý prostředek dokazují vnitřní politiku, kterou jste zamýšleli. Potom klienta znovu připojte a opakujte, protože název a adresa tunelového rozhraní se mohou mezi relacemi změnit. Pokud se výsledek liší, opravte rozsah zóny, místo abyste pravidlo rozšířili.