iptables: luba VPN-kliendil jõuda ainult ühe hostini

Kaks näiliselt mitteseotud tugipiletit osutuvad ühe põhjuse jagajateks. Esimeses soovib administraator, et server võtaks vastu ühendusi ainult tunnelist; teises peaksid VPN-i kasutajad jõudma ühe sisemise hostini ja mitte kaugemale. Mõlemad poliitikad kuuluvad FORWARD-i ja mõlemat proovitakse tavaliselt INPUT-is. Tulemus näeb välja nagu tulemüür ja käitub nagu kohatäide.

Milline kett vastab sinu küsimusele

Paketid, mille VPN-klient saadab LAN-i hostile või edasi internetti, suunab kern edasi ja neid hinnatakse FORWARD-is. INPUT ja OUTPUT näevad ainult liiklust, mis lõpeb serveris endas või algab sealt. Seega kaitseb kõige tagasilükkamine, mis ei saabu tun0-lt, serveri enda kuulajaid, ja lõpetab ka sinu SSH-seansi, kui olemasolevaid vooge esmalt ei lubata. See ei muuda midagi selles, kuhu klientidel minna lubatakse.

Nimeta esmalt küsimus: kes tohib serverini jõuda või kuhu tohivad kliendid minna. Enamik võrke vajab mõlemat vastust, erinevates kettides.

Esmalt olek, siis luba, siis keeld

Lubatud loend toimib ainult siis, kui konkreetne luba asub üldisest keelust kõrgemal ja kui tagasiliiklus on lubatud mõlemast kõrgemal. Sisesta reeglid selgetesse positsioonidesse ja väljasta siis kett käsuga iptables -S FORWARD, et järjekord oleks nähtav, mitte oletatud.

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

Kaks detaili otsustavad, kas see peab vastu kokkupuutele tegeliku liiklusega. Ilma olekureeglita hinnatakse vastused just lubatud ühendustele ise keelu vastu ja visatakse kõrvale. Piiramata LOG-reegel võib esimesel skaneerimisel väikese partitsiooni täis kirjutada, seega lisa -m limit --limit 10/min enne logimise jätkamist. REJECT tagastab vea kohe, mis on loendi häälestamise ajal sõbralikum; DROP viskab vaikselt kõrvale, nii et iga viga näib ajutõrkena. Vali üks meelega ja kirjuta valik muudatuse kirjesse.

Edastamine ja NAT peavad juba töötama

Filtreerimine ei suuda tõestada, et tee olemas on. Kõigepealt kinnita, et kern üldse edastab, ja tee see seade püsivaks, mitte ühekordseks kestakäsuks. Filter on viimane kiht, mitte esimene.

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

Kuhu maskeerimine kuulub, sõltub sellest, kust kliendid väljuvad. Kui nad lahkuvad tunneli kaudu kaugvõrku, läheb NAT-reegel sellele liidesele, mitte WAN-liidesele. Seejärel vaata loendureid: kui POSTROUTING-i loendur ei liigu kunagi, samal ajal kui FORWARD-i lubamiste arv kasvab, on tagasitee katki ja filter on korras. See lugemine säästab pärastlõuna reeglite ümberkirjutamisest, mis kunagi probleem ei olnud.

Meiliblokk kuulub ühe keti võrra edasi

Pordi 25 blokeerimine INPUT-is peatab ainult VPN-serverile adresseeritud meili. Tunneli kaudu meili saatvat rünnatud klienti edastatakse, seega peab blokk asuma FORWARD-is 465 ja 587 kõrval. Kui üks rakendus edastab meili seaduslikult, pane selle sihtkoht ja port sellest reeglist kõrgemale.

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

Lase keeldumiste loenduril nädal aega töötada, enne kui midagi muud pingutad. Arv, mis lakkab kasvamast, on seaduslik voog, mille sa just katki tegid.

Loe see tagasi ja tõesta siis kliendi pealt

Loe reeglistikku nii, nagu kern seda raporteerib, mitte nii, nagu sinu skript selle kirjutas. Alusta käsuga iptables -S FORWARD, siis NAT-tabel käsuga iptables -t nat -L POSTROUTING -n -v, siis uuritava voo conntrack-kirje. Hoia tagasipööramiskäsku või ajastatud tühjendust seni, kuni töö kestab. Iga kutse vajab -w, muidu põrkuvad kaks administraatorit xtables-i lukul. Midagi sellest ei ole muudatuste aknas valikuline.

Lõpeta testides kliendist kogumi sees ja sellest väljaspool. Reegel, mis töötab ainult masinast, kuhu sa selle trükkisid, ei ole poliitika.