Zo vergrendel je de Linux-uitgang zodat er niets weglekt als de VPN wegvalt

Stel je een mediabox op een thuisverbinding voor die het internet alleen via een tunnel hoort te bereiken. Als de tunnel wegvalt, hoort de toepassing stil te vallen in plaats van rustig door te gaan over de fysieke interface. Dat gedrag krijgen is een firewallprobleem en geen routeringsprobleem, en het onderscheid is belangrijk omdat een route vervangen kan worden door een herstart van de daemon, terwijl een filter blijft staan waar je het hebt neergezet. Hierna volgt hoe het pakketpad werkelijk beslist, en dan hoe de uitzonderingen te begrenzen die de tunnel opnieuw laten verbinden.

Lokale uitvoer is een andere haak dan doorsturen

Een pakket dat een toepassing op de machine verlaat gaat door de uitvoerhaak; een pakket dat de machine voor een andere host routeert, gaat door doorsturen. Een beleid dat alleen forward noemt, beperkt het tweede en laat het eerste wijd open, en daarom zien zoveel uitgangsvergrendelingen er correct uit en doen niets. Interface-matching hoort in dezelfde regel: oifname "tun0" accept laat verkeer door dat al via de tunnel is gerouteerd. Routering en filtering blijven ook aparte beslissingen, dus een uplink-route kan bestaan terwijl het filter het pakket weigert. Op die scheiding vertrouw je.

Een gateway die voor andere apparaten doorstuurt, heeft beide haken nodig. Alleen de uitvoer vergrendelen beschermt de machine zelf en laat elke client verderop vrij om te lekken.

Schrijf de uitzonderingenlijst van het eindpunt naar buiten

Begin bij het eindpunt van de tunnel: één bestemmingsadres of een kleine goedgekeurde set, het transportprotocol en de bestemmingspoort, bijvoorbeeld udp dport 1194 ip daddr 203.0.113.7 accept. Als de client een hostnaam oplost, heeft de initiële DNS-uitwisseling een eigen regel nodig, beperkt tot de resolver en tot poort 53, niet een algemene toestemming voor het adres van die resolver. Elke uitzondering hoort de reden te noemen waarom ze bestaat. Een toestemming voor al het UDP-verkeer naar de VPN-poort dekt veel meer dan de ene geauthenticeerde dienst die je voor ogen had.

De initiële resolutie is waar vergrendelingen meestal wegrotten. Een adresset dat op een timer ververst, heeft gedefinieerd gedrag nodig wanneer het verversen mislukt, en dat gedrag kan niet zijn de verbinding openen tot het lukt. Ververs via de tunnel zolang de tunnel staat, en val anders terug op het laatst bekende gezonde eindpunt.

Lokaal beheer verdient dezelfde behandeling. Een beheersubnet is niet betrouwbaar omdat de adressen privé zijn, en een regel die erop vertrouwt, nodigt een tweede pad om de vergrendeling heen uit.

Interface-matching is geen bewijs van een gezonde tunnel

Regels die alles accepteren wat tun0 verlaat, nemen aan dat een pakket op die interface uit de tunnel kwam. Interfacenamen worden opnieuw aangemaakt, en een naam is geen cryptografische identiteit. De peer kan ook weg zijn terwijl de interface blijft staan, wat de regel tot een zeer overtuigende no-op maakt.

Verbindingsregistratie voegt een verwante valkuil toe. Een brede regel voor bestaande verbindingen speelt de toestemming opnieuw af die een flow eerder kreeg, zodat een sessie die begon voordat de tunnel wegviel, daarna blijft werken. Beperk stateful acceptatie tot de interfaces en adressen die je werkelijk bedoelt, anders heb je een vergrendeling gebouwd die zichzelf opent. Invoer- en uitvoerregels beantwoorden ook verschillende vragen, en het ene harden terwijl je het andere negeert, laat de machine bereikbaar in de richting waar je niet aan dacht.

Wat een crash van de daemon overleeft

Een filter dat door een script wordt geïnstalleerd dat draait nadat de tunnel opkomt, verdwijnt samen met de tunnel, precies op het moment dat het nodig was. Laad de vergrendeling bij het opstarten en laat de daemon alleen zijn uitzonderingen beheren.

De standaardroute verwijderen is ook geen vervanging. De route is toestand die de daemon bezit en herschrijft, en het weghalen kan het pad ontnemen dat nodig is om opnieuw te verbinden. IPv6 heeft zijn eigen plan nodig, omdat buurontdekking en routeraankondigingen linkdiensten zijn die moeten blijven werken terwijl gewoon verkeer geblokkeerd is. DHCP hoort in dezelfde categorie. Schrijf deze dingen op als uitzonderingen met een doel, in plaats van ze later als storingen te ontdekken.

Herstelpad vóór uitrol

Test de vergrendeling zoals zij zal falen: opstarten zonder tunnel, de daemon doden, het eindpunt wijzigen en opnieuw verbinden. Elk geval hoort de toepassingen te laten stilvallen en het herstelkanaal te laten werken. Doe het vanaf een console, want een externe shell is de sessie die het meest waarschijnlijk door je eigen regel wordt buitengesloten.

Controleer daarna wat een gewone toepassing nog kan bereiken, met een onschadelijke bestemming en een verzoek dat je kunt verifiëren. Het resultaat dat je wilt is een weigering op de uplink en succes via de tunnel, geen dubbelzinnige time-out die beide kan betekenen. Houd de regelset onder dezelfde eigenaar als de rest van de firewall in plaats van de hele tabel te vervangen vanuit een shellscript. Een beleid waarin elke toestemming zichzelf kan rechtvaardigen is meer waard dan een lange regelset die niemand kan uitleggen.