Nödstopp för en VPN-sidecar: blockera trafiken när den avslutas

En applikationscontainer som delar en VPN-containers nätverksnamnrymd har inget eget gränssnitt, så det är lätt att anta att den inte kan skicka något när tunneln fallerar. Det antagandet är fel i det felmod som spelar roll. Om VPN-processen dör medan namnrymden överlever behåller applikationen sina sockets och namnrymden behåller sina rutter, och trafiken fortsätter på den väg som fortfarande är installerad. En riktig kill switch är en explicit filtreringspolicy plus tester av körtidsmiljöns livscykel, inte ett startberoende.

Varför delad namnrymd inte är en kill switch

Att dela en namnrymd betyder att appen använder VPN-containerns gränssnitt, adresser och routingtabell. Det tar bort appens oberoende väg till nätet så länge den delade namnrymden är intakt, och det säger ingenting om vad den namnrymden gör när tunneln försvinner.

Beroendevillkor i Compose kan fördröja en apps start tills ett beroende är friskt. Det täcker ett enda ögonblick och inget senare fel, så det är ett verktyg för startordning och inte en beständig utgående brandvägg.

Vad som faktiskt händer när containern avslutas

Skilj på tre händelser. VPN-processen i containern kan dö medan containern fortsätter att köra. Containern kan stoppas eller tas bort, vilket förstör namnrymden. Containern kan återskapas, vilket bygger en ny namnrymd och nya regler.

I det första fallet består namnrymden, standardrutten kan fortfarande peka på det fysiska gränssnittet, och applikationen fortsätter att skicka direkt. I det andra fallet tappar den beroende appen vanligtvis anslutningen helt, eftersom dess namnrymd försvann. I det tredje fallet kan appen ansluta igen till en ny namnrymd innan tunneln är klar. Varje fall kräver ett annat test, och en design som bara täcker den ordnade frånkopplingen täcker det minst intressanta.

Bygg en explicit utgående policy

Skriv policyn inne i den delade namnrymden så att den gäller appens paket. Formen är ett standarddrop med snäva undantag: loopback, tunnelns gränssnitt och den specifika slutpunktsadressen och porten som tunneltransporten behöver.

Undantaget för slutpunkten måste finnas på plats innan tunneln kommer upp, annars når VPN-klienten inte sin server. Därför tillåter regeluppsättningen den yttre transporten explicit i stället för att tillåta det fysiska gränssnittet generellt. Lägg också till IPv6-regler om namnrymden har IPv6-anslutning, eftersom en policy som bara gäller IPv4 lämnar den andra familjen öppen.

DNS hör också till policyn. Om appen slår upp namn via en resolver som bara är nåbar inne i tunneln bryter dropregeln uppslagningen när tunneln är nere, och det är det korrekta beteendet för en kill switch. Bestäm medvetet om det är det du vill.

Testa livscykeln, inte bara frånkopplingen

Skicka en ny ofarlig begäran medan tunneln är frisk, döda sedan VPN-processen och skicka en till. Upprepa efter ett containerstopp, efter en omstart och efter återskapande. En ny begäran spelar roll eftersom en befintlig anslutning kan överleva en regeländring som blockerar nya.

Förlita dig inte på en hälsokontroll eller en uppslagning av utgående IP som blockeringsmekanism. En kontroll observerar tillståndet och rapporterar det; en policy styr trafiken. Båda hör hemma i samma utrullning, och de ersätter inte varandra.

Skriv ned reglerna så att testet överlever en uppdatering

Skriv det förväntade resultatet för varje fel fall i driftsättningsdokumentationen, tillsammans med reglerna som genomför det. Den anteckningen gör det möjligt att köra samma test efter en image-uppdatering eller en körtidsuppgradering, när namnrymdsbeteende eller standardrutter kan ändras utan att någon redigerar compose-filen.

Håll VPN-slutpunktens nödvändiga yttre väg åtskild från obegränsad applikationsutgång, och håll DNS och IPv6 inom den avsedda täckningen. Om policyn tillåter hela det fysiska gränssnittet för enkelhetens skull är kill switchen borta. Docker-nätverksdokumentationen beskriver ordningen med delad namnrymd som policyn bygger på, och det är referensen att kontrollera när körtidsmiljöns beteende är ifrågasatt.