Kill switch voor een VPN-sidecar: blokkeer verkeer wanneer hij stopt

Een applicatiecontainer die de netwerknamespace van een VPN-container deelt, heeft geen eigen interface, dus het is makkelijk om aan te nemen dat hij niets kan versturen als de tunnel uitvalt. Die aanname is onjuist in de faalmodus die ertoe doet. Als het VPN-proces sterft terwijl de namespace blijft bestaan, behoudt de applicatie zijn sockets en behoudt de namespace zijn routes, en het verkeer gaat verder over het pad dat nog is geïnstalleerd. Een echte kill switch is een expliciet filterbeleid plus tests van de levenscyclus van de runtime, geen opstartafhankelijkheid.

Waarom een namespace delen geen kill switch is

Een namespace delen betekent dat de app de interfaces, adressen en routetabel van de VPN-container gebruikt. Het verwijdert het onafhankelijke pad van de app naar het netwerk zolang de gedeelde namespace intact is, en het zegt niets over wat die namespace doet wanneer de tunnel verdwijnt.

Afhankelijkheidsvoorwaarden van Compose kunnen het opstarten van een app uitstellen tot een afhankelijkheid gezond is. Dat dekt één moment in de tijd en geen latere fout, dus het is een hulpmiddel voor opstartvolgorde en geen doorlopende uitgaande firewall.

Wat er werkelijk gebeurt als de container stopt

Onderscheid drie gebeurtenissen. Het VPN-proces in de container kan sterven terwijl de container blijft draaien. De container kan stoppen of worden verwijderd, wat de namespace vernietigt. De container kan opnieuw worden gemaakt, wat een nieuwe namespace en nieuwe regels bouwt.

In het eerste geval blijft de namespace bestaan, kan de standaardroute nog naar de fysieke interface wijzen, en blijft de applicatie direct verzenden. In het tweede geval verliest de afhankelijke app meestal de verbinding volledig, omdat zijn namespace verdwenen is. In het derde geval kan de app opnieuw verbinden met een verse namespace voordat de tunnel klaar is. Elk geval vraagt een andere test, en een ontwerp dat alleen de nette verbreking dekt, dekt de minst interessante.

Bouw een expliciet uitgaand beleid

Schrijf het beleid binnen de gedeelde namespace zodat het geldt voor de pakketten van de applicatie. De vorm is een standaarddrop met smalle uitzonderingen: loopback, de interface van de tunnel, en het specifieke eindpuntadres en de poort die het tunneltransport nodig heeft.

De uitzondering voor het eindpunt moet er staan voordat de tunnel omhoog komt, anders kan de VPN-client zijn server niet bereiken. Daarom staat de regelset het buitenste transport expliciet toe in plaats van de fysieke interface in het algemeen toe te staan. Voeg ook IPv6-regels toe als de namespace IPv6-connectiviteit heeft, want een beleid dat alleen IPv4 dekt laat de andere familie open.

DNS hoort ook bij het beleid. Als de app namen oplost via een resolver die alleen binnen de tunnel bereikbaar is, breekt de dropregel de resolutie wanneer de tunnel weg is, en dat is het juiste gedrag voor een kill switch. Beslis bewust of dat is wat je wilt.

Test de levenscyclus, niet alleen de verbreking

Stuur een verse onschadelijke aanvraag terwijl de tunnel gezond is, dood daarna het VPN-proces en stuur er nog een. Herhaal dit na een containerstop, na een herstart en na opnieuw aanmaken. Een verse aanvraag is belangrijk omdat een bestaande verbinding een regelwijziging kan overleven die nieuwe blokkeert.

Vertrouw niet op een gezondheidscontrole of een exit-IP-opzoeking als het blokkeermechanisme. Een controle observeert de toestand en rapporteert die; een beleid beheert het verkeer. Beide horen in dezelfde uitrol, en ze zijn geen vervangers van elkaar.

Leg de regels vast zodat de test een update overleeft

Schrijf de verwachte uitkomst voor elk faalgeval in de uitroldocumentatie, samen met de regels die het implementeren. Die vastlegging maakt het mogelijk dezelfde test te draaien na een image-update of een runtime-upgrade, wanneer namespacegedrag of standaardroutes kunnen veranderen zonder dat iemand het composebestand bewerkt.

Houd het vereiste buitenste pad van het VPN-eindpunt gescheiden van onbeperkte applicatie-uitgang, en houd DNS en IPv6 binnen de bedoelde dekking. Als het beleid voor het gemak de hele fysieke interface toestaat, is de kill switch weg. De netwerkdocumentatie van Docker beschrijft de gedeelde-namespace-opstelling waarop het beleid is gebouwd, en dat is de referentie om te controleren wanneer het gedrag van de runtime twijfelachtig is.