Kill switch pro VPN sidecar: zablokujte provoz, když skončí

Aplikační kontejner, který sdílí síťový jmenný prostor kontejneru VPN, nemá vlastní rozhraní, takže je snadné předpokládat, že při selhání tunelu nemůže nic odeslat. Tento předpoklad je v režimu selhání, na kterém záleží, nesprávný. Pokud proces VPN zemře, zatímco jmenný prostor přežije, aplikace si ponechá své sockety a jmenný prostor si ponechá své trasy a provoz pokračuje po jakékoli cestě, která je stále nainstalovaná. Skutečný kill switch je explicitní filtrační politika plus testy životního cyklu runtime, ne závislost při startu.

Proč sdílení jmenného prostoru není kill switch

Sdílení jmenného prostoru znamená, že aplikace používá rozhraní, adresy a směrovací tabulku kontejneru VPN. Odstraňuje nezávislou cestu aplikace do sítě, dokud je sdílený jmenný prostor neporušený, a neříká nic o tom, co tento jmenný prostor udělá, když tunel zmizí.

Podmínky závislostí Compose mohou odložit start aplikace, dokud není závislost zdravá. To pokrývá jeden okamžik v čase a žádné pozdější selhání, takže jde o nástroj pro pořadí startu, nikoli nepřetržitý odchozí firewall.

Co se skutečně stane, když kontejner skončí

Rozlišujte tři události. Proces VPN uvnitř kontejneru může zemřít, zatímco kontejner běží dál. Kontejner se může zastavit nebo odstranit, což zničí jmenný prostor. Kontejner lze znovu vytvořit, což vytvoří nový jmenný prostor a nová pravidla.

V prvním případě jmenný prostor přetrvává, výchozí trasa může stále ukazovat na fyzické rozhraní a aplikace posílá data přímo dál. Ve druhém případě závislá aplikace obvykle ztratí konektivitu úplně, protože její jmenný prostor zmizel. Ve třetím případě se aplikace může znovu připojit k novému jmennému prostoru dřív, než je tunel připravený. Každý případ vyžaduje jiný test a návrh, který pokrývá jen spořádané odpojení, pokrývá ten nejméně zajímavý.

Vytvořte explicitní politiku odchozího provozu

Napište politiku uvnitř sdíleného jmenného prostoru, aby se vztahovala na pakety aplikace. Tvarem je výchozí zahazování s úzkými výjimkami: loopback, rozhraní tunelu a konkrétní adresa a port koncového bodu, které transport tunelu potřebuje.

Výjimka pro koncový bod musí existovat dřív, než tunel naběhne, jinak se klient VPN nedostane na svůj server. Proto sada pravidel povoluje vnější transport výslovně, místo aby povolila fyzické rozhraní obecně. Přidejte také pravidla IPv6, pokud má jmenný prostor konektivitu IPv6, protože politika pouze pro IPv4 nechává druhou rodinu otevřenou.

DNS patří do politiky také. Pokud aplikace překládá názvy přes resolver dostupný jen uvnitř tunelu, pravidlo zahazování přeruší překlad, když je tunel dole, což je pro kill switch správné chování. Rozhodněte se vědomě, zda to je to, co chcete.

Testujte životní cyklus, ne jen odpojení

Pošlete nový neškodný požadavek, dokud je tunel zdravý, pak zabijte proces VPN a pošlete další. Opakujte po zastavení kontejneru, po restartu a po novém vytvoření. Nový požadavek je důležitý, protože existující spojení může přežít změnu pravidel, která blokuje nová.

Nespoléhejte na zdravotní kontrolu ani na vyhledání výstupní IP jako na blokovací mechanismus. Kontrola pozoruje stav a hlásí ho; politika řídí provoz. Obě patří do stejného nasazení a nejsou zaměnitelné.

Zaznamenejte pravidla, aby test přežil aktualizaci

Napište očekávaný výsledek pro každý případ selhání do dokumentace nasazení spolu s pravidly, která ho implementují. Takový záznam umožní spustit stejný test po aktualizaci image nebo upgradu runtime, kdy se chování jmenného prostoru nebo výchozí trasy mohou změnit, aniž by kdokoli upravoval soubor Compose.

Udržujte požadovanou vnější cestu koncového bodu VPN oddělenou od neomezeného odchozího provozu aplikace a udržujte DNS a IPv6 v zamýšleném pokrytí. Pokud politika povolí celé fyzické rozhraní pro pohodlí, kill switch je pryč. Dokumentace sítí Docker popisuje uspořádání sdíleného jmenného prostoru, na kterém je politika postavena, a je odkazem, který je třeba zkontrolovat, když je chování runtime zpochybněno.