iptables: la VPN-klienter nå én vert og ingenting annet

Regelen du vil ha, står i FORWARD, ikke i INPUT. Tillat én destinasjon for VPN-poolen, avvis resten, og bevis det deretter med tellere og en tilbakerullingskommando.

To støttebilletter som ser urelaterte ut viser seg å dele én årsak. I den første vil en administrator at serveren bare skal godta tilkoblinger fra tunnelen; i den andre skal VPN-brukere nå én intern vert og ikke mer. Begge policyene hører i FORWARD, og begge forsøkes vanligvis i INPUT. Resultatet ser ut som en brannmur og oppfører seg som en plassholder.

Hvilken kjede svarer på spørsmålet ditt

Pakker som en VPN-klient sender til en vert på LAN, eller videre til internett, videresendes av kjernen og vurderes i FORWARD. INPUT og OUTPUT ser bare trafikk som terminerer på serveren selv eller stammer fra den. En avvisning for alt som ikke ankommer på tun0 beskytter derfor serverens egne lyttere, og den vil også avslutte SSH-økten din med mindre etablerte strømmer tillates først. Det endrer ingenting på hvor klienter får gå.

Navngi spørsmålet først: hvem kan nå serveren, eller hvor kan klienter gå. De fleste nettverk trenger begge svarene, i ulike kjeder.

Først tilstanden, så tillatelsen, så avvisningen

En tillatelsesliste virker bare hvis den spesifikke tillatelsen står over den generelle avvisningen, og hvis returtrafikk tillates over begge. Sett inn regler på eksplisitte posisjoner, og dump deretter kjeden med iptables -S FORWARD slik at rekkefølgen er synlig i stedet 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 detaljer avgjør om dette overlever møtet med ekte trafikk. Uten tilstandsregelen blir svar på tilkoblingene du nettopp tillot, selv vurdert mot avvisningen og droppet. En ubegrenset LOG-regel kan fylle en liten partisjon første gang en skanning treffer den, så legg til -m limit --limit 10/min før du fortsetter å logge. REJECT returnerer en feil umiddelbart, noe som er vennligere mens du finjusterer listen; DROP forkaster i stillhet, så hver feil fremstår som en tidsavbrudd. Velg én med vilje og skriv valget i endringsloggen.

Videresending og NAT må allerede virke

Filtrering kan ikke bevise at en vei finnes. Bekreft først at kjernen i det hele tatt videresender, og gjør den innstillingen varig i stedet for en engangskommando i skallet. Filteret er det siste laget, ikke det første.

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

Hvor maskeringen hører hjemme avhenger av hvor klientene går ut. Hvis de forlater via tunnelen mot et fjernt nettverk, skal NAT-regelen på det grensesnittet i stedet for WAN-grensesnittet. Se så på tellerne: hvis POSTROUTING-telleren aldri beveger seg mens antallet aksepter i FORWARD stiger, er returveien brutt og filteret er i orden. Den lesningen sparer en ettermiddag med å skrive om regler som aldri var problemet.

Mailblokkeringen hører en kjede lenger borte

Blokkering av port 25 i INPUT stopper bare e-post adressert til VPN-serveren. En kompromittert klient som sender e-post gjennom tunnelen, blir videresendt, så blokkeringen må ligge i FORWARD ved siden av 465 og 587. Hvis én applikasjon lovlig videresender e-post, setter du destinasjonen og porten over den regelen.

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

La avvisningstelleren gå i en uke før du strammer noe annet. Tallet som slutter å klatre, er den legitime strømmen du nettopp brøt.

Les det tilbake, og bevis det deretter fra en klient

Les regelsettet slik kjernen rapporterer det, ikke slik skriptet ditt skrev det. Start med iptables -S FORWARD, deretter NAT-tabellen med iptables -t nat -L POSTROUTING -n -v, deretter conntrack-oppføringen for strømmen du undersøker. Hold en tilbakerullingskommando eller en planlagt tømming så lenge arbeidet varer. Hvert kall trenger -w, ellers kolliderer to administratorer på xtables-låsen. Ingenting av dette er valgfritt i et endringsvindu.

Avslutt med å teste fra en klient inne i poolen og fra en utenfor den. En regel som bare virker fra maskinen du skrev den på, er ikke en policy.

Relaterte artikler