Kill switch til en VPN-sidecar: bloker trafikken, når den afsluttes

En applikationscontainer, der deler en VPN-containers netværksnavnerum, har ikke sin egen grænseflade, så det er let at antage, at den ikke kan sende noget, når tunnelen svigter. Den antagelse er forkert i den fejltilstand, der betyder noget. Hvis VPN-processen dør, mens navnerummet overlever, beholder applikationen sine sockets, og navnerummet beholder sine ruter, og trafikken fortsætter ad den sti, der stadig er installeret. En rigtig kill switch er en eksplicit filtreringspolitik plus test af runtime'ens livscyklus, ikke en opstartsafhængighed.

Hvorfor deling af et navnerum ikke er en kill switch

At dele et navnerum betyder, at appen bruger VPN-containerens grænseflader, adresser og rutetabel. Det fjerner appens uafhængige vej til netværket, mens det delte navnerum er intakt, og det siger intet om, hvad navnerummet vil gøre, når tunnelen forsvinder.

Compose-afhængighedsbetingelser kan udskyde en apps opstart, indtil en afhængighed er sund. Det dækker ét øjeblik og ingen senere fejl, så det er et værktøj til opstartsrækkefølge snarere end en vedvarende egress-firewall.

Hvad der faktisk sker, når containeren afsluttes

Skeln mellem tre hændelser. VPN-processen inde i containeren kan dø, mens containeren fortsat kører. Containeren kan stoppe eller fjernes, hvilket ødelægger navnerummet. Containeren kan genskabes, hvilket bygger et nyt navnerum og nye regler.

I det første tilfælde består navnerummet, standardruten kan stadig pege på den fysiske grænseflade, og applikationen bliver ved med at sende direkte. I det andet tilfælde mister den afhængige app normalt forbindelsen helt, fordi dens navnerum forsvandt. I det tredje tilfælde kan appen genoprette forbindelse til et frisk navnerum, før tunnelen er klar. Hvert tilfælde kræver en anden test, og et design, der kun dækker den ordentlige afbrydelse, dækker det mindst interessante.

Byg en eksplicit egress-politik

Skriv politikken inde i det delte navnerum, så den gælder for appens pakker. Formen er et standard-drop med snævre undtagelser: loopback, tunnelets grænseflade og den specifikke endpoint-adresse og -port, som tunneltransporten har brug for.

Undtagelsen for endpointet skal være på plads, før tunnelen er oppe, ellers kan VPN-klienten ikke nå sin server. Derfor tillader regelsættet den ydre transport eksplicit i stedet for at tillade den fysiske grænseflade generelt. Tilføj også IPv6-regler, hvis navnerummet har IPv6-forbindelse, fordi en politik, der kun gælder IPv4, lader den anden familie stå åben.

DNS hører også med i politikken. Hvis appen slår navne op via en resolver, der kun kan nås inde i tunnelen, vil drop-reglen bryde opløsningen, når tunnelen er nede, hvilket er den korrekte adfærd for en kill switch. Beslut bevidst, om det er det, du vil have.

Test livscyklussen, ikke kun afbrydelsen

Send en frisk uskadelig anmodning, mens tunnelen er sund, dræb derefter VPN-processen, og send en mere. Gentag efter et containerstop, efter en genstart og efter genskabelse. En frisk anmodning er vigtig, fordi en eksisterende forbindelse kan overleve en regelændring, der blokerer nye.

Stol ikke på et sundhedstjek eller et exit-IP-opslag som blokeringsmekanismen. Et tjek observerer tilstanden og rapporterer den; en politik styrer trafikken. De to hører til i samme udrulning, og de er ikke erstatninger.

Registrér reglerne, så testen overlever en opdatering

Skriv det forventede resultat for hvert fejltilfælde ned i udrulningsdokumentationen sammen med de regler, der implementerer det. Den registrering gør det muligt at køre den samme test efter en image-opdatering eller en runtime-opgradering, hvor navnerumsadfærd eller standardruter kan ændre sig, uden at nogen redigerer compose-filen.

Hold VPN-endpointets krævede ydre sti adskilt fra ubegrænset applikations-egress, og hold DNS og IPv6 inden for den tilsigtede dækning. Hvis politikken tillader hele den fysiske grænseflade for nemheds skyld, er kill switchen væk. Docker-netværksdokumentationen beskriver den delte-navnerums-ordning, som politikken er bygget på, og det er referencen at tjekke, når der er tvivl om runtime'ens adfærd.