iptables: lad VPN-klienter nå én vært og intet andet

Reglen, du vil have, står i FORWARD, ikke i INPUT. Tillad én destination for VPN-puljen, afvis resten, og bevis det derefter med tællere og en tilbagerulningskommando.

To supportbilletter, der ser ubeslægtede ud, viser sig at dele én årsag. I den første vil en administrator have serveren til kun at acceptere forbindelser fra tunnelen; i den anden skal VPN-brugere nå én intern vært og intet mere. Begge politikker hører i FORWARD, og begge forsøges normalt i INPUT. Resultatet ser ud som en firewall og opfører sig som en pladsholder.

Hvilken kæde besvarer dit spørgsmål

Pakker, som en VPN-klient sender til en vært på LAN, eller videre til internettet, videresendes af kernen og vurderes i FORWARD. INPUT og OUTPUT ser kun trafik, der terminerer på serveren selv eller stammer fra den. En afvisning af alt, der ikke ankommer på tun0, beskytter derfor serverens egne lyttere og vil også afslutte din SSH-session, medmindre etablerede flows tillades først. Det ændrer intet ved, hvor klienter må hen.

Navngiv først spørgsmålet: hvem må nå serveren, eller hvor må klienter gå hen. De fleste netværk har brug for begge svar, i forskellige kæder.

Først tilstanden, så tilladelsen, så afvisningen

En tilladelsesliste virker kun, hvis den specifikke tilladelse står over den generelle afvisning, og hvis returtrafik tillades over begge. Indsæt regler på eksplicitte positioner, og dump derefter kæden med iptables -S FORWARD, så rækkefølgen er synlig i stedet for antaget.

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 afgør, om dette overlever mødet med rigtig trafik. Uden tilstandsreglen bliver svar på de forbindelser, du netop har tilladt, selv vurderet mod afvisningen og droppet. En ubegrænset LOG-regel kan udtømme en lille partition første gang en scanning rammer den, så tilføj -m limit --limit 10/min, før du fortsætter med at logge. REJECT returnerer en fejl med det samme, hvilket er venligere, mens du finjusterer listen; DROP kasserer lydløst, så enhver fejl fremstår som en timeout. Vælg én med vilje, og skriv valget i ændringsloggen.

Videresendelse og NAT skal allerede virke

Filtrering kan ikke bevise, at en vej findes. Bekræft først, at kernen overhovedet videresender, og gør den indstilling permanent i stedet for en engangskommando i shellen. Filteret er det sidste lag, 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 til, afhænger af, hvor klienterne går ud. Hvis de forlader via tunnelen mod et fjernt netværk, skal NAT-reglen på det interface i stedet for WAN-interfacet. Se så på tællerne: hvis POSTROUTING-tælleren aldrig rykker, mens antallet af accepter i FORWARD stiger, er returvejen brudt, og filteret er fint. Den læsning sparer en eftermiddag med at omskrive regler, der aldrig var problemet.

Mailblokeringen hører en kæde længere henne

Blokering af port 25 i INPUT stopper kun mail adresseret til VPN-serveren. En kompromitteret klient, der sender mail gennem tunnelen, videresendes, så blokeringen skal ligge i FORWARD ved siden af 465 og 587. Hvis én applikation lovligt videresender mail, så sæt dens destination og port over den regel.

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

Lad afvisningstælleren køre i en uge, før du strammer noget andet. Tallet, der holder op med at stige, er det legitime flow, du netop har brudt.

Læs det tilbage, og bevis det derefter fra en klient

Læs regelsættet, som kernen rapporterer det, ikke som dit script skrev det. Start med iptables -S FORWARD, derefter NAT-tabellen med iptables -t nat -L POSTROUTING -n -v, derefter conntrack-posteringen for det flow, du undersøger. Hold en tilbagerulningskommando eller en planlagt flush, så længe arbejdet varer. Hvert kald kræver -w, ellers kolliderer to administratorer på xtables-låsen. Intet af det er valgfrit i et ændringsvindue.

Afslut med at teste fra en klient inde i puljen og fra en uden for den. En regel, der kun virker fra den maskine, du skrev den på, er ikke en politik.

Relaterede artikler