iptables: lat VPN-klientar nå éin vert og ingen andre

To støttebillettar som ser urelaterte ut viser seg å dele éi årsak. I den fyrste vil ein administrator at tenaren berre skal godta tilkoplingar frå tunnelen; i den andre skal VPN-brukarar nå éin intern vert og ikkje meir. Begge retningslinjene høyrer i FORWARD, og begge vert vanlegvis prøvde i INPUT. Resultatet ser ut som ein brannmur og oppfører seg som ein plasshaldar.

Kva kjede svarar på spørsmålet ditt

Pakkar som ein VPN-klient sender til ein vert på LAN, eller vidare til internett, vert vidaresende av kjernen og vurderte i FORWARD. INPUT og OUTPUT ser berre trafikk som terminerer på tenaren sjølv eller stammar frå han. Ei avvising for alt som ikkje kjem inn på tun0 vernar derfor tenaren sine eigne lyttarar, og ho vil òg avslutte SSH-økta di med mindre etablerte straumar vert tillatne fyrst. Det endrar ingenting på kvar klientar får gå.

Namngje spørsmålet fyrst: kven kan nå tenaren, eller kvar kan klientar gå. Dei fleste nettverk treng begge svara, i ulike kjeder.

Fyrst tilstanden, så løyvet, så avvisinga

Ei tillatingsliste verkar berre om det spesifikke løyvet står over den generelle avvisinga, og om returtrafikk vert tillaten over begge. Set inn reglar på eksplisitte posisjonar, og dump deretter kjeda med iptables -S FORWARD slik at rekkjefølgja er synleg i staden for antatt.

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

To detaljar avgjer om dette overlever møtet med ekte trafikk. Utan tilstandsregelen vert svar på tilkoplingane du nettopp tillét, sjølve vurderte mot avvisinga og droppa. Ein ubegrensa LOG-regel kan fylla ein liten partisjon fyrste gong ein skanning treff han, så legg til -m limit --limit 10/min før du held fram med logginga. REJECT returnerer ein feil med ein gong, noko som er venlegare medan du finjusterer lista; DROP kastar i stillheit, så kvar feil framstår som eit tidsavbrot. Vel éin med vilje og skriv valet i endringsloggen.

Vidaresending og NAT må allereie verke

Filtrering kan ikkje prova at ein veg finst. Stadfest fyrst at kjernen i det heile vidaresender, og gjer den innstillinga varig i staden for ein eingongskommando i skalet. Filteret er det siste laget, ikkje det fyrste.

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

Kvar maskeringa høyrer heime avheng av kvar klientane går ut. Om dei forlèt via tunnelen mot eit fjernt nettverk, skal NAT-regelen på det grensesnittet i staden for WAN-grensesnittet. Sjå så på teljarane: om POSTROUTING-teljaren aldri rører seg medan talet på aksepter i FORWARD stig, er returvegen broten og filteret er i orden. Den lesinga sparar ein ettermiddag med å skriva om reglar som aldri var problemet.

E-postblokkeringa høyrer éi kjede lenger borte

Blokkering av port 25 i INPUT stoppar berre e-post adressert til VPN-tenaren. Ein kompromittert klient som sender e-post gjennom tunnelen, vert vidaresend, så blokkeringa må liggja i FORWARD ved sida av 465 og 587. Om éin applikasjon lovleg vidaresender e-post, set destinasjonen og porten over den regelen.

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

Lat avvisingsteljaren gå i ei veke før du strammar noko anna. Talet som sluttar å klatra, er den legitime straumen du nettopp braut.

Les det tilbake, og prov det deretter frå ein klient

Les regelsettet slik kjernen rapporterer det, ikkje slik skriptet ditt skreiv det. Start med iptables -S FORWARD, deretter NAT-tabellen med iptables -t nat -L POSTROUTING -n -v, deretter conntrack-oppføringa for straumen du undersøkjer. Hald ein tilbakerullingskommando eller ein planlagd tømming så lenge arbeidet varer. Kvar kall treng -w, elles kolliderer to administratorar på xtables-låsen. Ingenting av dette er valfritt i eit endringsvindauge.

Avslutt med å testa frå ein klient inne i poolen og frå ein utanfor han. Ein regel som berre verkar frå maskinen du skreiv han på, er ikkje ein policy.