Kill switch for en VPN-sidecar: blokker trafikken når den avsluttes

En applikasjonscontainer som deler nettverksnavnerommet til en VPN-container har ikke sitt eget grensesnitt, så det er lett å anta at den ikke kan sende noe når tunnelen svikter. Den antakelsen er feil i feilmodusen som betyr noe. Hvis VPN-prosessen dør mens navnerommet overlever, beholder applikasjonen socketene sine og navnerommet beholder rutene sine, og trafikken fortsetter på den banen som fortsatt er installert. En ekte kill switch er en eksplisitt filtreringspolicy pluss tester av livssyklusen til kjøretidsmiljøet, ikke en oppstartsavhengighet.

Hvorfor deling av navnerom ikke er en kill switch

Å dele et navnerom betyr at appen bruker grensesnittene, adressene og rutetabellen til VPN-containeren. Det fjerner appens uavhengige vei til nettverket så lenge det delte navnerommet er intakt, og det sier ingenting om hva navnerommet vil gjøre når tunnelen forsvinner.

Compose-avhengighetsbetingelser kan utsette oppstarten av en app til en avhengighet er sunn. Det dekker ett øyeblikk i tid og ingen senere feil, så det er et verktøy for oppstartsrekkefølge og ikke en vedvarende utgangsbrannmur.

Hva som faktisk skjer når containeren avsluttes

Skill mellom tre hendelser. VPN-prosessen inne i containeren kan dø mens containeren fortsatt kjører. Containeren kan stoppe eller fjernes, noe som ødelegger navnerommet. Containeren kan gjenskapes, noe som bygger et nytt navnerom og nye regler.

I det første tilfellet består navnerommet, standardruten kan fortsatt peke på det fysiske grensesnittet, og applikasjonen fortsetter å sende direkte. I det andre tilfellet mister den avhengige appen vanligvis tilkoblingen helt, fordi navnerommet dens forsvant. I det tredje tilfellet kan appen koble til et ferskt navnerom før tunnelen er klar. Hvert tilfelle krever en annen test, og et design som bare dekker den ordentlige frakoblingen dekker den minst interessante.

Bygg en eksplisitt utgangspolicy

Skriv policyen inne i det delte navnerommet slik at den gjelder pakkene til appen. Formen er en standarddropp med smale unntak: loopback, grensesnittet til tunnelen, og den konkrete endepunktadressen og porten som tunneltransporten trenger.

Unntaket for endepunktet må være på plass før tunnelen kommer opp, ellers kan ikke VPN-klienten nå serveren sin. Derfor tillater regelsettet den ytre transporten eksplisitt i stedet for å tillate det fysiske grensesnittet generelt. Legg også til IPv6-regler hvis navnerommet har IPv6-tilkobling, fordi en policy som bare gjelder IPv4 lar den andre familien stå åpen.

DNS hører også med i policyen. Hvis appen slår opp navn via en resolver som bare er tilgjengelig inne i tunnelen, vil droppregelen bryte oppslaget når tunnelen er nede, og det er den riktige oppførselen for en kill switch. Bestem bevisst om det er det du vil.

Test livssyklusen, ikke bare frakoblingen

Send en fersk ufarlig forespørsel mens tunnelen er sunn, drep deretter VPN-prosessen og send en til. Gjenta etter en containerstopp, etter en omstart og etter gjenskaping. En fersk forespørsel betyr noe fordi en eksisterende tilkobling kan overleve en regelendring som blokkerer nye.

Ikke stol på en helsesjekk eller et exit-IP-oppslag som blokkeringsmekanismen. En sjekk observerer tilstanden og rapporterer den; en policy styrer trafikken. De to hører til i samme utrulling, og de er ikke erstatninger.

Skriv ned reglene slik at testen overlever en oppdatering

Skriv det forventede resultatet for hvert feiltilfelle inn i utrullingsdokumentasjonen, sammen med reglene som implementerer det. Den registreringen gjør det mulig å kjøre den samme testen etter en image-oppdatering eller en kjøretidsoppgradering, når navneromsoppførsel eller standardruter kan endres uten at noen redigerer compose-filen.

Hold den påkrevde ytre banen til VPN-endepunktet atskilt fra ubegrenset applikasjonsutgang, og hold DNS og IPv6 innenfor den tiltenkte dekningen. Hvis policyen tillater hele det fysiske grensesnittet for enkelhets skyld, er kill switchen borte. Docker-nettverksdokumentasjonen beskriver ordningen med delt navnerom som policyen bygger på, og det er referansen å sjekke når oppførselen til kjøretidsmiljøet er usikker.