iptables: pustite klientov VPN len k jednému hostiteľovi

Dve tikety podpory, ktoré vyzerajú nesúvisle, majú napokon jednu príčinu. V prvom chce správca, aby server prijímal pripojenia len z tunela; v druhom majú používatelia VPN dosiahnuť jeden interný hostiteľ a nič viac. Obe politiky patria do FORWARD a obe sa zvyčajne skúšajú v INPUT. Výsledok vyzerá ako firewall a správa sa ako zástupný symbol.

Ktorý reťazec odpovedá na vašu otázku

Pakety, ktoré klient VPN posiela hostiteľovi v LAN alebo ďalej do internetu, jadro preposiela a vyhodnocujú sa vo FORWARD. INPUT a OUTPUT vidia len prevádzku, ktorá končí na samotnom serveri alebo z neho vychádza. Odmietnutie všetkého, čo neprichádza cez tun0, preto chráni vlastných poslucháčov servera a tiež ukončí vašu reláciu SSH, ak sa najskôr nepovolia nadviazané toky. Na tom, kam klienti smú, to nič nemení.

Najprv pomenujte otázku: kto smie dosiahnuť server alebo kam smú klienti ísť. Väčšina sietí potrebuje obe odpovede, v rôznych reťazcoch.

Najprv stav, potom povolenie, potom odmietnutie

Zoznam povolení funguje len vtedy, keď konkrétne povolenie stojí nad všeobecným odmietnutím a keď je spätná prevádzka povolená nad oboma. Vložte pravidlá na výslovné pozície a potom vypíšte reťazec pomocou iptables -S FORWARD, aby bol poriadok viditeľný, a nie predpokladaný.

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ú, či to prežije stretnutie s reálnou prevádzkou. Bez pravidla stavu sa odpovede na práve povolené spojenia samy vyhodnocujú proti odmietnutiu a zahadzujú. Pravidlo LOG bez obmedzenia môže pri prvom skene zaplniť malý oddiel, preto pred ďalším logovaním pridajte -m limit --limit 10/min. REJECT vracia chybu hneď, čo je pri ladení zoznamu prívetivejšie; DROP zahadzuje ticho, takže každá chyba vyzerá ako vypršanie času. Vyberte jedno zámerne a voľbu zapíšte do záznamu o zmene.

Preposielanie a NAT už musia fungovať

Filtrovanie nedokáže dokázať, že cesta existuje. Najprv overte, že jadro vôbec preposiela, a toto nastavenie urobte trvalým, nie jednorazovým príkazom v shelli. Filter je posledná vrstva, nie prvá.

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

Kam maskarádovanie patrí, závisí od toho, kadiaľ klienti vychádzajú. Ak odchádzajú tunelom do vzdialenej siete, pravidlo NAT patrí na toto rozhranie, nie na rozhranie WAN. Potom sledujte čítače: ak sa čítač POSTROUTING nikdy nepohne, kým počet prijatí vo FORWARD rastie, spätná cesta je pokazená a filter je v poriadku. Toto čítanie ušetrí popoludnie prepisovania pravidiel, ktoré nikdy neboli problémom.

Blok pošty patrí o reťazec ďalej

Blokovanie portu 25 v INPUT zastaví len poštu adresovanú serveru VPN. Kompromitovaný klient, ktorý posiela poštu tunelom, sa preposiela, preto blok musí byť vo FORWARD vedľa 465 a 587. Ak jedna aplikácia posiela poštu legitímne, dajte jej destináciu a port nad toto pravidlo.

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

Nechajte čítač odmietnutí bežať týždeň, kým čokoľvek ďalšie utiahnete. Číslo, ktoré prestane rásť, je legitímny tok, ktorý ste práve rozbili.

Prečítajte si to späť a potom to dokážte z klienta

Čítajte sadu pravidiel tak, ako ju hlási jadro, nie ako ju napísal váš skript. Začnite s iptables -S FORWARD, potom tabuľka NAT s iptables -t nat -L POSTROUTING -n -v, potom záznam conntrack pre skúmaný tok. Kým práca trvá, majte po ruke príkaz na návrat alebo naplánované vyčistenie. Každé volanie potrebuje -w, inak sa dvaja správcovia zrazia na zámku xtables. Nič z toho nie je v okne zmien voliteľné.

Skončite testom z klienta vnútri fondu a z klienta mimo neho. Pravidlo, ktoré funguje len zo stroja, na ktorom ste ho napísali, nie je politika.