iptables: päästä VPN-asiakkaat vain yhteen isäntään

Kaksi näennäisesti irrallista tukipyyntöä osoittautuvat saman syyn aiheuttamiksi. Ensimmäisessä ylläpitäjä haluaa palvelimen hyväksyvän yhteyksiä vain tunnelista; toisessa VPN-käyttäjien pitäisi päästä yhteen sisäiseen isäntään eikä mihinkään muuhun. Molemmat käytännöt kuuluvat FORWARD-ketjuun, ja molempia yritetään yleensä INPUT-ketjussa. Tulos näyttää palomuurilta ja käyttäytyy kuin paikkamerkki.

Mikä ketju vastaa kysymykseesi

Paketit, jotka VPN-asiakas lähettää lähiverkon isännälle tai edelleen internetiin, ydin välittää eteenpäin ja ne arvioidaan FORWARD-ketjussa. INPUT ja OUTPUT näkevät vain liikenteen, joka päättyy palvelimeen itseensä tai lähtee siitä. Siksi kaiken, mikä ei saavu tun0-rajapinnalle, hylkääminen suojaa palvelimen omia kuuntelijoita, ja se myös päättää SSH-istuntosi, ellei vakiintuneita virtauksia hyväksytä ensin. Se ei muuta mitään siinä, minne asiakkaat saavat mennä.

Nimeä ensin kysymys: kuka saa päästä palvelimelle tai minne asiakkaat saavat mennä. Useimmat verkot tarvitsevat molemmat vastaukset, eri ketjuissa.

Ensin tila, sitten lupa, sitten kielto

Sallittujen luettelo toimii vain, jos yksittäinen lupa on yleisen kiellon yläpuolella ja jos paluuliikenne sallitaan molempien yläpuolella. Lisää säännöt täsmällisiin kohtiin ja tulosta sitten ketju komennolla iptables -S FORWARD, jotta järjestys on näkyvissä eikä oletettu.

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

Kaksi yksityiskohtaa ratkaisee, kestääkö tämä kosketuksen todelliseen liikenteeseen. Ilman tilasääntöä vastaukset juuri sallimiisi yhteyksiin arvioidaan itse kieltoa vastaan ja pudotetaan. Rajoittamaton LOG-sääntö voi täyttää pienen osion ensimmäisellä skannauksella, joten lisää -m limit --limit 10/min ennen kuin jatkat kirjaamista. REJECT palauttaa virheen heti, mikä on ystävällisempää luetteloa säätäessäsi; DROP hylkää hiljaa, joten jokainen virhe näyttää aikakatkaisulta. Valitse yksi tarkoituksella ja kirjoita valinta muutostietueeseen.

Edelleenvälityksen ja NATin on jo toimittava

Suodatus ei voi todistaa, että polku on olemassa. Varmista ensin, että ydin välittää ylipäätään, ja tee asetuksesta pysyvä eikä kertaluonteinen komento kuoressa. Suodatin on viimeinen kerros, ei ensimmäinen.

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

Maskerauksen paikka riippuu siitä, mistä asiakkaat lähtevät. Jos he lähtevät tunnelin kautta etäverkkoon, NAT-sääntö menee sille rajapinnalle eikä WAN-rajapinnalle. Katso sitten laskureita: jos POSTROUTING-laskuri ei koskaan liiku, kun taas FORWARD-hyväksyntöjen määrä kasvaa, paluupolku on rikki ja suodatin on kunnossa. Tämä luenta säästää iltapäivän sellaisten sääntöjen uudelleenkirjoittamiselta, jotka eivät koskaan olleet ongelma.

Sähköpostilohko kuuluu yhtä ketjua ylemmäs

Portin 25 estäminen INPUT-ketjussa pysäyttää vain VPN-palvelimelle osoitetun sähköpostin. Tunnelin kautta sähköpostia lähettävä murrettu asiakas välitetään eteenpäin, joten lohkon on oltava FORWARD-ketjussa 465:n ja 587:n vieressä. Jos yksi sovellus välittää sähköpostia laillisesti, laita sen kohde ja portti kyseisen säännön yläpuolelle.

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

Anna hylkäyslaskurin käydä viikko ennen kuin kiristät mitään muuta. Luku, joka lakkaa kasvamasta, on se laillinen virtaus, jonka juuri rikoit.

Lue se takaisin ja todista sitten asiakkaalta

Lue sääntöjoukko niin kuin ydin sen raportoi, ei niin kuin skriptisi sen kirjoitti. Aloita iptables -S FORWARD-komennolla, sitten NAT-taulukko komennolla iptables -t nat -L POSTROUTING -n -v, sitten tutkittavan virtauksen conntrack-merkintä. Pidä palautuskomento tai ajastettu tyhjennys saatavilla niin kauan kuin työ kestää. Jokainen kutsu tarvitsee -w, muuten kaksi ylläpitäjää törmäävät xtables-lukossa. Mikään tästä ei ole valinnaista muutosikkunan aikana.

Lopeta testaamalla asiakkaalta ryhmän sisältä ja toiselta sen ulkopuolelta. Sääntö, joka toimii vain koneelta, jolla sen kirjoitit, ei ole käytäntö.