iptables: laat VPN-clients één host bereiken en niets anders

De regel die u wilt, staat in FORWARD, niet in INPUT. Sta één bestemming toe voor de VPN-pool, weiger de rest en bewijs het daarna met tellers en een terugdraaicommando.

Twee supporttickets die los van elkaar lijken, delen uiteindelijk één oorzaak. In het eerste wil een beheerder dat de server alleen verbindingen uit de tunnel accepteert; in het tweede moeten VPN-gebruikers één interne host bereiken en niets meer. Beide policies horen in FORWARD, en beide worden meestal in INPUT geprobeerd. Het resultaat ziet eruit als een firewall en gedraagt zich als een plaatsaanduiding.

Welke keten beantwoordt uw vraag

Pakketten die een VPN-client naar een host op de LAN of verder naar het internet stuurt, worden door de kernel doorgestuurd en in FORWARD beoordeeld. INPUT en OUTPUT zien alleen verkeer dat op de server zelf eindigt of daarvan afkomstig is. Een weigering voor alles wat niet op tun0 aankomt, beschermt dus de eigen luisteraars van de server, en beëindigt ook uw SSH-sessie tenzij gevestigde stromen eerst worden toegestaan. Het verandert niets aan waar clients mogen komen.

Benoem eerst de vraag: wie mag de server bereiken, of waar mogen clients heen. De meeste netwerken hebben beide antwoorden nodig, in verschillende ketens.

Eerst de toestand, dan de toestemming, dan de weigering

Een toegangslijst werkt alleen als de specifieke toestemming boven de algemene weigering staat en als retourverkeer boven beide wordt toegestaan. Voeg regels op expliciete posities in en dump dan de keten met iptables -S FORWARD, zodat de volgorde zichtbaar is in plaats van aangenomen.

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

Twee details bepalen of dit het contact met echt verkeer overleeft. Zonder de toestandsregel worden antwoorden op de verbindingen die u zojuist hebt toegestaan, zelf tegen de weigering beoordeeld en weggegooid. Een onbeperkte LOG-regel kan een kleine partitie vullen zodra een scan hem raakt, dus voeg -m limit --limit 10/min toe voordat u blijft loggen. REJECT geeft direct een fout terug, wat vriendelijker is terwijl u de lijst afstelt; DROP gooit stil weg, zodat elke fout als een time-out verschijnt. Kies er één bewust en schrijf de keuze in het wijzigingsrecord.

Doorgifte en NAT moeten al werken

Filteren kan niet bewijzen dat een pad bestaat. Bevestig eerst dat de kernel sowieso doorstuurt, en maak die instelling permanent in plaats van een eenmalig shellcommando. Het filter is de laatste laag, niet de eerste.

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

Waar de masquerade hoort, hangt af van waar clients naar buiten gaan. Als ze via de tunnel naar een extern netwerk vertrekken, staat de NAT-regel op die interface in plaats van op de WAN-interface. Kijk dan naar de tellers: als de POSTROUTING-teller nooit beweegt terwijl het aantal acceptaties in FORWARD stijgt, is het retourpad kapot en is het filter in orde. Die lezing bespaart een middag regels herschrijven die nooit het probleem waren.

Het mailblok hoort één keten verder

Poort 25 in INPUT blokkeren stopt alleen mail die aan de VPN-server is gericht. Een gecompromitteerde client die mail door de tunnel stuurt, wordt doorgestuurd, dus het blok moet in FORWARD naast 465 en 587 staan. Als één applicatie mail legitiem doorgeeft, zet dan de bestemming en de poort boven die regel.

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

Laat de weigeringsteller een week lopen voordat u iets anders strakker zet. Het getal dat stopt met stijgen is de legitieme stroom die u zojuist hebt gebroken.

Lees het terug en bewijs het dan vanaf een client

Lees de regelset zoals de kernel die rapporteert, niet zoals uw script hem schreef. Begin met iptables -S FORWARD, dan de NAT-tabel met iptables -t nat -L POSTROUTING -n -v, dan de conntrack-regel voor de stroom die u onderzoekt. Houd een terugdraaicommando of een geplande flush bij de hand zolang het werk duurt. Elke aanroep heeft -w nodig, anders botsen twee beheerders op het xtables-slot. Niets daarvan is optioneel tijdens een wijzigingsvenster.

Sluit af met testen vanaf een client binnen de pool en vanaf een daarbuiten. Een regel die alleen werkt vanaf de machine waarop u hem typte, is geen beleid.

Gerelateerde artikelen