iptables-host alleen met VPN: noem het tun-apparaat, niet tun+

-o tun+ schrijven voelt als een precieze instructie en is in werkelijkheid een jokerteken dat elke tunnel van de kernel dekt. Een tweede VPN-client, een containerbrug of een interface die een gecrashte sessie heeft achtergelaten voldoen er allemaal aan, en de host laat dan verkeer door dat het beleid juist wilde tegenhouden. De procedure hieronder legt één apparaatnaam vast, ordent de uitzonderingen zodat de tunnel echt kan ontstaan, en laat je een weg terug als de regels slecht uitpakken. Elke stap is kort genoeg om hem los ongedaan te maken.

Stap 1: noteer de regels die je nu hebt

Voordat je een standaardbeleid wijzigt, sla je de huidige toestand op zodat de terugdraaiing een commando is en geen herinnering. iptables-save > /root/iptables.pre schrijft elke tabel naar een bestand dat je kunt herstellen, en een tweede terminal met een open root-sessie is geen paranoia wanneer het beleid dat je gaat instellen de verbinding laat vallen die het draagt. Werk je op afstand, plan dan ook een flush als noodschakelaar.

Lijst vervolgens de interfaces op, want een naam die je aannam is een naam die je had moeten lezen: ip -br link toont wat er nu bestaat, en de tunnel verschijnt pas als hij omhoog is. Schrijf de apparaatnamen op terwijl je ze leest.

Stap 2: geef de tunnel zijn eigen naam

OpenVPN accepteert dev tun_work in de clientconfiguratie, en Linux maakt dan een interface met precies die naam aan in plaats van tun0 toe te wijzen. De naam blijft stabiel tussen herverbindingen zolang niets anders er aanspraak op maakt, en dat is wat een regel die het apparaat benoemt betekenisvol maakt.

Waar de naam niet kan worden beheerd, match dan op het tunneladres of een pakketmarkering. Beide werken, beide zijn lastiger te lezen, en beide falen stiller wanneer de tunnel opnieuw nummert. Match hoe dan ook op één ding en zeg duidelijk welk.

Stap 3: schrijf het beleid met de uitzondering voor het endpoint eerst

Een host alleen met VPN is een host met standaardweigering en een korte uitzonderingenlijst, en de uitzondering die het meest telt is degene die de tunnel laat bestaan. Bouw hem in deze volgorde op, met de endpoint-regel vóór de tunnelapparaatregel, zodat de handshake ergens heen kan:

# allow the tunnel to be built, then everything the tunnel carries
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o tun_work -j ACCEPT
iptables -A INPUT  -i tun_work -j ACCEPT
iptables -A INPUT  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Het letterlijke endpointadres en de poort zijn van je provider, niet van deze pagina. Is het endpoint een hostnaam, los die dan één keer op en leg het resultaat vast, want een regel kan geen naam opzoeken en een roterend antwoord breekt het beleid stil na de volgende DNS-wijziging. Controleer ook de poort, want providers die je naar TCP 443 verplaatsen hebben anders een regel nodig die niemand heeft opgeschreven. Een tunnel die maar op één protocol werkt is meestal precies deze weglating en geen fout in de firewall.

Op een router gaat dezelfde vorm de FORWARD-keten in voor de clients erachter, en het eigen verkeer van de router heeft eigen regels nodig. Een regelset die alleen doorgestuurde pakketten dekt, laat SSH en DNS op het oude pad, en zo wordt een router onbereikbaar op het moment dat de tunnel omhoog komt.

Stap 4: controleer de volgorde, niet alleen de aanwezigheid

Regels worden op volgorde geëvalueerd, dus een ACCEPT die eerder komt verbergt simpelweg de REJECT die je daarna hebt toegevoegd. De overeenkomst voor established en related is wat antwoorden op je eigen uitgaande verzoeken laat terugkomen zonder een algemeen inkomend pad te openen, en hem na de tunnelacceptatie plaatsen betekent dat een weggevallen tunnel nog steeds retourverkeer op zijn eigen interface doorlaat.

Houd het aantal regels klein genoeg om op één scherm te lezen. Een regelset die je niet kunt auditen is er een die je zult pleisteren door bovenaan uitzonderingen toe te voegen, en zo krijgen standaardweigeringsbeleidsregels geleidelijk een standaardtoestemmingsrand. Tel de ACCEPT's voor en na de wijziging.

Stap 5: zorg dat het de opstart en de adresfamilie overleeft

Handmatig ingevoerde regels verdwijnen bij een herstart, dus laad ze uit de firewalldienst van de distributie of uit een unit die draait nadat de tunnelinterface bestaat. Verwijzen naar tun_work in een script dat draait voordat OpenVPN start, is een gangbare manier om een opstartlus met weggevallen verkeer te maken.

Controleer daarna IPv6 apart, want een goed standaardweigeringsbeleid voor IPv4 zegt niets over de andere familie. ip -6 route vertelt je of de host een route heeft die verkeer rond een tunnel kan dragen die alleen IPv4 afhandelt, en ip6tables of nftables heeft zijn eigen equivalente regels nodig. Test met een IPv6-only-bestemming in plaats van op de symmetrie van de regelset te vertrouwen.

Stap 6: verifieer en wees klaar om te herstellen

Breng de tunnel omhoog, bevestig dat de bedoelde dienst werkt en probeer dan iets wat het beleid hoort te weigeren. Herstel met iptables-restore < /root/iptables.pre als het antwoord je verrast, en begin pas daarna regels te bewerken. Volharding plus een getest herstelpad is wat dit een wijziging maakt die je twee keer kunt doen.