iptables: pusťte klienty VPN jen k jednomu hostiteli

Pravidlo, které chcete, patří do FORWARD, ne do INPUT. Povolte jednu destinaci pro fond VPN, zbytek odmítněte a pak to dokažte čítači a příkazem pro návrat.

Dva tikety podpory, které vypadají nesouvisele, mají nakonec jednu příčinu. V prvním chce správce, aby server přijímal připojení pouze z tunelu; ve druhém mají uživatelé VPN dosáhnout jednoho interního hostitele a nic víc. Obě politiky patří do FORWARD a obě se obvykle zkoušejí v INPUT. Výsledek vypadá jako firewall a chová se jako zástupný symbol.

Který řetěz odpovídá na vaši otázku

Pakety, které klient VPN posílá hostiteli v LAN nebo dál do internetu, jádro předává a vyhodnocuje ve FORWARD. INPUT a OUTPUT vidí jen provoz, který končí na serveru nebo z něj vychází. Odmítnutí všeho, co nepřichází na tun0, proto chrání vlastní naslouchače serveru a také ukončí vaši relaci SSH, pokud se nejdřív nepovolí navázané toky. Na tom, kam klienti smějí, to nic nemění.

Nejprve pojmenujte otázku: kdo smí dosáhnout serveru, nebo kam smějí klienti. Většina sítí potřebuje obě odpovědi, v různých řetězech.

Nejdřív stav, pak povolení, pak odmítnutí

Seznam povolených funguje jen tehdy, když konkrétní povolení stojí nad obecným odmítnutím a když je zpětný provoz povolen nad oběma. Vložte pravidla na explicitní pozice a pak řetěz vypište pomocí iptables -S FORWARD, aby byl pořádek vidět, a ne předpokládán.

POOL=10.99.0.0/24
iptables -I FORWARD 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD 2 -s "$POOL" -d 172.31.20.15 -p tcp -m multiport --dports 443,3389 -j ACCEPT
iptables -I FORWARD 3 -s "$POOL" -j REJECT

Dva detaily rozhodují, zda tohle přežije střet s reálným provozem. Bez pravidla stavu se odpovědi na právě povolená spojení sama vyhodnocují proti odmítnutí a zahazují. Pravidlo LOG bez omezení může při prvním skenu zaplnit malý oddíl, takže před dalším logováním přidejte -m limit --limit 10/min. REJECT vrací chybu hned, což je při ladění seznamu přívětivější; DROP zahazuje tiše, takže každá chyba vypadá jako vypršení času. Vyberte jedno záměrně a volbu zapište do záznamu o změně.

Předávání a NAT už musí fungovat

Filtrování nedokáže prokázat, že cesta existuje. Nejprve ověřte, že jádro vůbec předává, a toto nastavení udělejte trvalým, ne jednorázovým příkazem v shellu. Filtr je poslední vrstva, ne první.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s "$POOL" -o eth0 -j MASQUERADE

Kam maskarádování patří, závisí na tom, kudy klienti vycházejí. Pokud odcházejí tunelem do vzdálené sítě, pravidlo NAT patří na toto rozhraní, ne na rozhraní WAN. Pak sledujte čítače: pokud se čítač POSTROUTING nikdy nehne, zatímco počet přijetí ve FORWARD roste, je zpětná cesta rozbitá a filtr je v pořádku. Toto čtení ušetří odpoledne přepisování pravidel, která nikdy nebyla problémem.

Blok pošty patří o řetěz výš

Blokování portu 25 v INPUT zastaví jen poštu adresovanou serveru VPN. Kompromitovaný klient, který posílá poštu tunelem, se předává, takže blok musí být ve FORWARD vedle 465 a 587. Pokud jedna aplikace poštu legitimně přeposílá, dejte její destinaci a port nad toto pravidlo.

iptables -I FORWARD 2 -s "$POOL" -p tcp -m multiport --dports 25,465,587 -j REJECT

Nechte čítač odmítnutí běžet týden, než cokoli dalšího utáhnete. Číslo, které přestane růst, je legitimní tok, který jste právě rozbili.

Přečtěte si to zpět a pak to dokažte z klienta

Čtěte sadu pravidel tak, jak ji hlásí jádro, ne jak ji napsal váš skript. Začněte iptables -S FORWARD, pak tabulka NAT s iptables -t nat -L POSTROUTING -n -v, pak záznam conntrack pro tok, který zkoumáte. Dokud práce trvá, mějte po ruce příkaz pro návrat nebo naplánované vyčištění. Každé volání potřebuje -w, jinak se dva správci srazí na zámku xtables. Nic z toho není v okně změn volitelné.

Skončete testem z klienta uvnitř fondu a z klienta mimo něj. Pravidlo, které funguje jen ze stroje, na kterém jste ho napsali, není politika.

Související články