iptables: pustite VPN klijente do jednog hosta i nigdje dalje

Dvije potpore koje izgledaju nepovezano na kraju dijele jedan uzrok. U prvoj administrator želi da server prihvata veze samo iz tunela; u drugoj VPN korisnici treba da dođu do jednog internog hosta i ništa više. Obje politike pripadaju FORWARD-u, a obje se obično pokušavaju u INPUT-u. Rezultat izgleda kao vatrozid, a ponaša se kao privremena zakrpa.

Koji lanac odgovara na vaše pitanje

Pakete koje VPN klijent šalje hostu na LAN-u ili dalje na internet kernel prosljeđuje i ocjenjuje u FORWARD-u. INPUT i OUTPUT vide samo saobraćaj koji završava na serveru ili iz njega potiče. Zato odbijanje svega što ne stiže na tun0 štiti vlastite slušaoce servera i prekinut će i vašu SSH sesiju ako uspostavljeni tokovi nisu prvo propušteni. To ništa ne mijenja u tome kuda klijenti smiju ići.

Prvo imenujte pitanje: ko smije doći do servera ili kuda klijenti smiju ići. Većini mreža trebaju oba odgovora, u različitim lancima.

Prvo stanje, zatim dozvola, zatim odbijanje

Lista dopuštenja radi samo ako specifična dozvola stoji iznad općeg odbijanja i ako je povratni saobraćaj propušten iznad oba. Umetnite pravila na izričite pozicije, pa ispišite lanac pomoću iptables -S FORWARD da redoslijed bude vidljiv, a ne pretpostavljen.

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 detalja odlučuju hoće li ovo izdržati susret sa stvarnim saobraćajem. Bez pravila stanja, odgovori na veze koje ste upravo dopustili sami se ocjenjuju prema odbijanju i bivaju odbačeni. LOG pravilo bez ograničenja može iscrpiti malu particiju već pri prvom skeniranju, zato dodajte -m limit --limit 10/min prije nego nastavite logirati. REJECT odmah vraća grešku, što je ljubaznije dok podešavate listu; DROP odbacuje tiho, pa se svaka greška predstavlja kao istek vremena. Odaberite jedno namjerno i upišite izbor u zapis o promjeni.

Prosleđivanje i NAT već moraju raditi

Filtriranje ne može dokazati da put postoji. Prvo potvrdite da kernel uopće prosljeđuje i učinite tu postavku trajnom, a ne jednokratnom naredbom u ljusci. Filter je posljednji sloj, ne prvi.

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

Gdje maskarada pripada zavisi od toga kuda klijenti izlaze. Ako izlaze kroz tunel prema udaljenoj mreži, NAT pravilo ide na to sučelje, a ne na WAN sučelje. Zatim gledajte brojače: ako se brojač POSTROUTING nikad ne pomjeri dok broj prihvaćanja u FORWARD-u raste, povratni put je pokvaren, a filter je u redu. To čitanje štedi popodne prepisivanja pravila koja nikad nisu bila problem.

Blok za poštu pripada jedan lanac dalje

Blokiranje porta 25 u INPUT-u zaustavlja samo poštu adresiranu na VPN server. Kompromitirani klijent koji šalje poštu kroz tunel se prosljeđuje, pa blok mora stajati u FORWARD-u pored 465 i 587. Ako jedna aplikacija legitimno prosljeđuje poštu, stavite njeno odredište i port iznad tog pravila.

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

Pustite brojač odbijanja sedmicu prije nego što bilo šta drugo zategnete. Broj koji prestane rasti je legitimni tok koji ste upravo pokvarili.

Pročitajte to natrag, pa dokažite s klijenta

Čitajte skup pravila onako kako ga kernel prijavljuje, ne kako ga je vaša skripta napisala. Počnite s iptables -S FORWARD, zatim NAT tabela s iptables -t nat -L POSTROUTING -n -v, zatim conntrack zapis za tok koji ispitujete. Držite naredbu za vraćanje ili zakazano čišćenje dok god posao traje. Svaki poziv treba -w, inače će se dva administratora sudariti na xtables bravi. Ništa od toga nije opcionalno u prozoru promjena.

Završite testiranjem s klijenta unutar bazena i s onog izvan njega. Pravilo koje radi samo s mašine na kojoj ste ga otipkali nije politika.