iptables: låt VPN-klienter nå en enda värd och inget annat

Regeln du vill ha finns i FORWARD, inte i INPUT. Tillåt en destination för VPN-poolen, avvisa resten och bevisa det sedan med räknare och ett återställningskommando.

Två supportärenden som ser orelaterade ut visar sig dela en orsak. I det första vill en administratör att servern bara ska acceptera anslutningar från tunneln; i det andra ska VPN-användare nå en enda intern värd och inget mer. Båda policyn hör hemma i FORWARD, och båda försöks vanligtvis i INPUT. Resultatet ser ut som en brandvägg och beter sig som en platshållare.

Vilken kedja svarar på din fråga

Paket som en VPN-klient skickar till en värd på LAN, eller vidare till internet, vidarebefordras av kärnan och utvärderas i FORWARD. INPUT och OUTPUT ser bara trafik som terminerar på servern själv eller härrör från den. En avvisning för allt som inte anländer på tun0 skyddar därför serverns egna lyssnare, och den avslutar också din SSH-session om inte etablerade flöden tillåts först. Det ändrar ingenting i fråga om vart klienter får gå.

Namnge frågan först: vem får nå servern, eller vart får klienter gå. De flesta nätverk behöver båda svaren, i olika kedjor.

Först tillståndet, sedan tillåtelsen, sedan avvisningen

En tillåtelselista fungerar bara om det specifika tillståndet står över den allmänna avvisningen och om returtrafik tillåts över båda. Infoga regler på uttryckliga positioner och dumpa sedan kedjan med iptables -S FORWARD så att ordningen syns i stället för antas.

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

Två detaljer avgör om detta överlever mötet med verklig trafik. Utan tillståndsregeln utvärderas svar på de anslutningar du just tillät själva mot avvisningen och släpps. En obegränsad LOG-regel kan fylla en liten partition första gången en skanning träffar den, så lägg till -m limit --limit 10/min innan du fortsätter logga. REJECT returnerar ett fel direkt, vilket är vänligare medan du justerar listan; DROP kastar tyst, så varje misstag framstår som en timeout. Välj en med avsikt och skriv valet i ändringsloggen.

Vidarebefordran och NAT måste redan fungera

Filtrering kan inte bevisa att en väg finns. Bekräfta först att kärnan överhuvudtaget vidarebefordrar, och gör den inställningen beständig i stället för ett engångskommando i skalet. Filtret är det sista lagret, inte det första.

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

Var maskeringen hör hemma beror på var klienterna går ut. Om de lämnar via tunneln mot ett avlägset nätverk ska NAT-regeln ligga på det gränssnittet i stället för WAN-gränssnittet. Titta sedan på räknarna: om POSTROUTING-räknaren aldrig rör sig medan antalet accepter i FORWARD stiger är returvägen trasig och filtret är i ordning. Den läsningen sparar en eftermiddag av att skriva om regler som aldrig var problemet.

Mailblocket hör en kedja längre bort

Att blockera port 25 i INPUT stoppar bara e-post adresserad till VPN-servern. En komprometterad klient som skickar e-post genom tunneln vidarebefordras, så blocket måste ligga i FORWARD bredvid 465 och 587. Om en applikation lagligt vidarebefordrar e-post, sätt dess destination och port ovanför den regeln.

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

Låt avvisningsräknaren gå i en vecka innan du stramar något annat. Talet som slutar klättra är det legitima flöde du just bröt.

Läs tillbaka det och bevisa det sedan från en klient

Läs regeluppsättningen som kärnan rapporterar den, inte som ditt skript skrev den. Börja med iptables -S FORWARD, sedan NAT-tabellen med iptables -t nat -L POSTROUTING -n -v, sedan conntrack-posten för det flöde du undersöker. Håll ett återställningskommando eller en schemalagd tömning så länge arbetet pågår. Varje anrop behöver -w, annars krockar två administratörer på xtables-låset. Inget av detta är valfritt i ett ändringsfönster.

Avsluta med att testa från en klient inne i poolen och från en utanför den. En regel som bara fungerar från maskinen du skrev den på är ingen policy.

Relaterade artiklar