Aplikacijski kontejner koji dijeli mrežni prostor imena VPN kontejnera nema vlastito sučelje, pa je lako pretpostaviti da ne može ništa poslati kada tunel zakaže. Ta je pretpostavka pogrešna u načinu kvara koji je važan. Ako VPN proces umre dok prostor imena preživi, aplikacija zadržava svoje sockete, a prostor imena zadržava svoje rute, i promet se nastavlja putem koji je još instaliran. Pravi kill switch je izričita politika filtriranja plus testovi životnog ciklusa runtimea, a ne ovisnost pri pokretanju.

Zašto dijeljenje prostora imena nije kill switch

Dijeljenje prostora imena znači da aplikacija koristi sučelja, adrese i tablicu ruta VPN kontejnera. To uklanja neovisni put aplikacije do mreže dok je zajednički prostor imena netaknut, i ne govori ništa o tome što će taj prostor imena učiniti kada tunel nestane.

Uvjeti ovisnosti u Composeu mogu odgoditi pokretanje aplikacije dok ovisnost ne bude zdrava. To pokriva jedan trenutak u vremenu i nijedan kasniji kvar, pa je to alat za redoslijed pokretanja, a ne trajni izlazni vatrozid.

Što se stvarno događa kada kontejner izađe

Razlikujte tri događaja. VPN proces unutar kontejnera može umrijeti dok kontejner nastavlja raditi. Kontejner se može zaustaviti ili ukloniti, što uništava prostor imena. Kontejner se može ponovno stvoriti, što gradi novi prostor imena i nova pravila.

U prvom slučaju prostor imena ostaje, zadana ruta može još pokazivati na fizičko sučelje, a aplikacija nastavlja slati izravno. U drugom slučaju ovisna aplikacija obično potpuno izgubi povezivost jer je njezin prostor imena nestao. U trećem slučaju aplikacija se može ponovno povezati s novim prostorom imena prije nego što je tunel spreman. Svaki slučaj traži drukčiji test, a dizajn koji pokriva samo uredan prekid pokriva onaj najmanje zanimljiv.

Izgradite izričitu politiku izlaznog prometa

Napišite politiku unutar zajedničkog prostora imena kako bi se primjenjivala na pakete aplikacije. Oblik je zadano odbacivanje s uskim iznimkama: loopback, sučelje tunela te određena adresa i port završne točke koje transport tunela treba.

Iznimka za završnu točku mora postojati prije nego što se tunel podigne, inače VPN klijent ne može dosegnuti svoj poslužitelj. Zato skup pravila izričito dopušta vanjski transport umjesto da dopušta fizičko sučelje općenito. Dodajte i IPv6 pravila ako prostor imena ima IPv6 povezivost, jer politika samo za IPv4 ostavlja drugu obitelj otvorenom.

DNS također pripada politici. Ako aplikacija razrješava imena preko razrješivača dostupnog samo unutar tunela, pravilo odbacivanja prekinut će razrješavanje kada tunel padne, što je ispravno ponašanje za kill switch. Odlučite svjesno je li to ono što želite.

Testirajte životni ciklus, ne samo prekid

Pošaljite svjež bezopasan zahtjev dok je tunel zdrav, zatim ubijte VPN proces i pošaljite još jedan. Ponovite nakon zaustavljanja kontejnera, nakon ponovnog pokretanja i nakon ponovnog stvaranja. Svjež zahtjev je važan jer postojeća veza može preživjeti promjenu pravila koja blokira nove.

Ne oslanjajte se na provjeru zdravlja ni na traženje izlazne IP adrese kao mehanizam blokiranja. Provjera promatra stanje i izvješćuje o njemu; politika kontrolira promet. Oboje pripada istoj implementaciji, i nisu zamjena jedno drugome.

Zabilježite pravila kako bi test preživio ažuriranje

Napišite očekivani ishod za svaki slučaj kvara u dokumentaciju implementacije, zajedno s pravilima koja ga provode. Taj zapis omogućuje pokretanje istog testa nakon ažuriranja slike ili nadogradnje runtimea, kada se ponašanje prostora imena ili zadane rute mogu promijeniti bez da itko uređuje compose datoteku.

Držite potrebni vanjski put VPN završne točke odvojenim od neograničenog izlaza aplikacije i držite DNS i IPv6 unutar predviđene pokrivenosti. Ako politika dopušta cijelo fizičko sučelje radi praktičnosti, kill switch je nestao. Docker dokumentacija o mrežama opisuje raspored zajedničkog prostora imena na kojem se politika temelji, i to je referenca koju treba provjeriti kada je ponašanje runtimea upitno.

Povezani članci