iptables: pustite odjemalce VPN le do enega gostitelja

Dve zahtevki za podporo, ki se zdita nepovezana, imata na koncu en vzrok. V prvem skrbnik želi, da strežnik sprejema povezave le iz tunela; v drugem naj bi uporabniki VPN dosegli enega notranjega gostitelja in nič več. Obe politiki spadata v FORWARD, obe pa se običajno poskušata v INPUT. Rezultat je videti kot požarni zid in se obnaša kot nadomestni znak.

Katera veriga odgovori na vaše vprašanje

Pakete, ki jih odjemalec VPN pošlje gostitelju v omrežju LAN ali naprej v internet, jedro posreduje in se ocenjujejo v FORWARD. INPUT in OUTPUT vidita le promet, ki se konča na strežniku samem ali iz njega izvira. Zato zavrnitev vsega, kar ne pride na tun0, ščiti lastne poslušalce strežnika in bo tudi prekinila vašo sejo SSH, razen če se najprej dovolijo vzpostavljeni tokovi. To ne spremeni ničesar glede tega, kam smejo odjemalci.

Najprej poimenujte vprašanje: kdo lahko doseže strežnik ali kam smejo odjemalci. Večina omrežij potrebuje oba odgovora, v različnih verigah.

Najprej stanje, nato dovoljenje, nato zavrnitev

Seznam dovoljenih deluje le, če je posebno dovoljenje nad splošno zavrnitvijo in če je povratni promet dovoljen nad obema. Vstavite pravila na izrecne položaje in nato izpišite verigo z iptables -S FORWARD, da bo vrstni red viden in ne predpostavljen.

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

Dve podrobnosti odločata, ali bo to prestalo stik z dejanskim prometom. Brez pravila stanja se odgovori na pravkar dovoljene povezave sami ocenjujejo glede na zavrnitev in zavržejo. Pravilo LOG brez omejitve lahko ob prvem skeniranju napolni majhno particijo, zato pred nadaljnjim beleženjem dodajte -m limit --limit 10/min. REJECT takoj vrne napako, kar je pri nastavljanju seznama prijaznejše; DROP zavrže tiho, zato je vsaka napaka videti kot potekla časovna omejitev. Izberite eno namenoma in izbiro zapišite v zapis o spremembi.

Posredovanje in NAT morata že delovati

Filtriranje ne more dokazati, da pot obstaja. Najprej preverite, ali jedro sploh posreduje, in to nastavitev naredite trajno, ne pa enkratnega ukaza v lupini. Filter je zadnja plast, ne prva.

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

Kam spada maskiranje, je odvisno od tega, kod odjemalci izstopajo. Če izstopajo skozi tunel v oddaljeno omrežje, pravilo NAT velja na tem vmesniku in ne na vmesniku WAN. Nato spremljajte števce: če se števec POSTROUTING nikoli ne premakne, medtem ko število dovolitev v FORWARD narašča, je povratna pot pokvarjena, filter pa je v redu. To branje prihrani popoldne prepisovanja pravil, ki nikoli niso bila težava.

Blok pošte spada eno verigo dlje

Blokiranje vrat 25 v INPUT ustavi le pošto, naslovljeno na strežnik VPN. Ogroženi odjemalec, ki pošilja pošto skozi tunel, se posreduje, zato mora blok stati v FORWARD ob 465 in 587. Če ena aplikacija zakonito posreduje pošto, postavite njen cilj in vrata nad to pravilo.

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

Pustite števec zavrnitev teči en teden, preden karkoli drugega zaostrite. Število, ki se neha vzpenjati, je zakonit tok, ki ste ga pravkar zlomili.

Preberite vse skupaj nazaj in nato dokažite z odjemalca

Berite nabor pravil tako, kot ga poroča jedro, ne tako, kot ga je napisala vaša skripta. Začnite s iptables -S FORWARD, nato tabela NAT z iptables -t nat -L POSTROUTING -n -v, nato vnos conntrack za tok, ki ga preizkušate. Med delom imejte pri roki ukaz za razveljavitev ali načrtovano čiščenje. Vsak klic potrebuje -w, sicer se bosta dva skrbnika zaletela na ključavnici xtables. Nič od tega ni v oknu sprememb neobvezno.

Zaključite s preizkusom z odjemalca v skladu in z odjemalca zunaj njega. Pravilo, ki deluje le s stroja, na katerem ste ga vtipkali, ni politika.