Kill-switch VPN-i sidecarile: blokeeri liiklus, kui see lõpeb

Rakenduse konteineril, mis jagab VPN-i konteineri võrgu nimeruumi, pole oma liidest, seega on lihtne eeldada, et see ei saa tunni rikke korral midagi saata. See eeldus on olulises rikkerežiimis vale. Kui VPN-i protsess sureb, samal ajal kui nimeruum püsib, säilitab rakendus oma soklid ja nimeruum oma marsruudid ning liiklus jätkub mööda seda teed, mis on veel paigaldatud. Tõeline kill-switch on selge filtreerimispoliitika pluss runtime’i elutsükli testid, mitte käivitussõltuvus.

Miks nimeruumi jagamine pole kill-switch

Nimeruumi jagamine tähendab, et rakendus kasutab VPN-i konteineri liideseid, aadresse ja marsruutitabelit. See eemaldab rakenduse iseseisva tee võrku seni, kuni jagatud nimeruum on terve, ja ei ütle midagi selle kohta, mida see nimeruum teeb, kui tunnel kaob.

Compose’i sõltuvustingimused võivad rakenduse käivitust edasi lükata, kuni sõltuvus on terve. See katab ühe hetke ajas ja mitte ühtegi hilisemat riket, seega on see käivituse järjestamise tööriist, mitte pidev väljundtulemüür.

Mis tegelikult juhtub, kui konteiner lõpeb

Erista kolme sündmust. VPN-i protsess konteineri sees võib surra, samal ajal kui konteiner jätkab töötamist. Konteiner võib peatuda või eemaldada, mis hävitab nimeruumi. Konteineri võib uuesti luua, mis ehitab uue nimeruumi ja uued reeglid.

Esimesel juhul püsib nimeruum, vaikemarsruut võib endiselt osutada füüsilisele liidesele ja rakendus jätkab otse saatmist. Teisel juhul kaotab sõltuv rakendus tavaliselt ühenduvuse täielikult, sest selle nimeruum kadus. Kolmandal juhul võib rakendus uuesti ühenduda värske nimeruumiga enne, kui tunnel on valmis. Iga juhtum vajab erinevat testi ja kujundus, mis katab ainult korrapärase katkestuse, katab kõige vähem huvitava.

Ehita selge väljundpoliitika

Kirjuta poliitika jagatud nimeruumi sees, et see kehtiks rakenduse pakettidele. Vorm on vaikimisi langetamine kitsaste eranditega: loopback, tunneli liides ning konkreetne lõpp-punkti aadress ja port, mida tunneli transport vajab.

Lõpp-punkti erand peab olema paigas enne, kui tunnel üles tuleb, muidu ei saa VPN-i klient oma serverini. Seetõttu lubab reeglistik välist transporti selgesõnaliselt, selle asemel et lubada füüsilist liidest üldiselt. Lisa ka IPv6 reeglid, kui nimeruumil on IPv6 ühenduvus, sest ainult IPv4 poliitika jätab teise perekonna avatuks.

DNS kuulub samuti poliitika juurde. Kui rakendus lahendab nimesid resolveri kaudu, mis on kättesaadav ainult tunneli sees, siis langetamise reegel katkestab lahendamise, kui tunnel on maas, mis on kill-switchi jaoks õige käitumine. Otsusta teadlikult, kas sa tahad seda.

Testi elutsüklit, mitte ainult katkestust

Saada värske kahjutu päring, kui tunnel on terve, seejärel tapa VPN-i protsess ja saada veel üks. Korda seda pärast konteineri peatamist, pärast taaskäivitust ja pärast uuesti loomist. Värske päring on oluline, sest olemasolev ühendus võib üle elada reeglimuudatuse, mis blokeerib uued.

Ära tugine tervisekontrollile ega väljumis-IP päringule blokeerimismehhanismina. Kontroll vaatleb olekut ja teavitab sellest; poliitika juhib liiklust. Mõlemad kuuluvad samasse juurutusse ja need ei asenda üksteist.

Kirjenda reeglid, et test jääks püsima ka uuenduse järel

Kirjuta iga rikkejuhtumi oodatav tulemus juurutamise dokumentatsiooni koos seda rakendavate reeglitega. See kirje võimaldab sama testi käivitada pärast kujutise uuendust või runtime’i täiendust, kui nimeruumi käitumine või vaikemarsruudid võivad muutuda ilma, et keegi compose-faili muudaks.

Hoia VPN-i lõpp-punkti nõutav väline tee eraldi piiramatust rakenduse väljundist ja hoia DNS ning IPv6 kavandatud katvuse sees. Kui poliitika lubab mugavuse huvides kogu füüsilist liidest, on kill-switch kadunud. Dockeri võrgustiku dokumentatsioon kirjeldab jagatud nimeruumi lahendust, millele poliitika on ehitatud, ja see on viide, mida kontrollida, kui runtime’i käitumine on kahtluse all.