Pamutol ng trapiko para sa sidecar ng VPN: harangin kapag lumabas ito
Ang pagbabahagi ng namespace ng container ng VPN ay hindi pumipigil sa app kapag namatay ang tunnel. Magdagdag ng tahasang patakaran sa paglabas at subukan ang mga restart, hindi lang mga pagkadiskonekta.
Ang container ng aplikasyon na nagbabahagi ng namespace ng network ng container ng VPN ay walang sariling interface, kaya madaling ipalagay na hindi ito makapagpapadala ng anuman kapag nabigo ang tunnel. Mali ang palagay na iyon sa failure mode na mahalaga. Kung mamatay ang proseso ng VPN habang nananatili ang namespace, pinapanatili ng aplikasyon ang mga socket nito at pinapanatili ng namespace ang mga ruta nito, at nagpapatuloy ang trapiko sa landas na naka-install pa rin. Ang tunay na kill switch ay isang tahasang patakaran sa pagsasala kasama ng mga pagsubok sa lifecycle ng runtime, hindi isang dependency sa pagsisimula.
Bakit hindi kill switch ang pagbabahagi ng namespace
Ang pagbabahagi ng namespace ay nangangahulugan na ginagamit ng app ang mga interface, address at routing table ng container ng VPN. Inaalis nito ang malayang landas ng app patungo sa network habang buo ang ibinabahaging namespace, at wala itong sinasabi tungkol sa gagawin ng namespace na iyon kapag nawala ang tunnel.
Maaaring ipagpaliban ng mga kundisyon ng dependency sa Compose ang pagsisimula ng app hanggang maging malusog ang isang dependency. Sinasaklaw nito ang isang sandali lamang at walang kasunod na pagkabigo, kaya ito ay kasangkapan sa pagkakasunod-sunod ng pagsisimula at hindi patuloy na firewall sa paglabas.
Ano ang talagang nangyayari kapag lumabas ang container
Tukuyin ang tatlong pangyayari. Maaaring mamatay ang proseso ng VPN sa loob ng container habang tumatakbo pa ito. Maaaring huminto o maalis ang container, na sumisira sa namespace. Maaaring likhain muli ang container, na bumubuo ng bagong namespace at bagong mga patakaran.
Sa unang kaso nananatili ang namespace, maaaring nakaturo pa rin ang default na ruta sa pisikal na interface, at patuloy na direktang nagpapadala ang app. Sa ikalawang kaso kadalasang tuluyang nawawala ang konektibidad ng dependent na app, dahil nawala ang namespace nito. Sa ikatlong kaso maaaring muling kumonekta ang app sa bagong namespace bago pa handa ang tunnel. Kailangan ng bawat kaso ng ibang pagsubok, at ang disenyong sumasaklaw lamang sa maayos na pagkadiskonekta ay sumasaklaw sa pinakamababang kawili-wili.
Bumuo ng tahasang patakaran sa paglabas
Isulat ang patakaran sa loob ng ibinabahaging namespace upang umiral para sa mga packet ng app. Ang anyo ay default na pagtapon na may makikitid na eksepsiyon: loopback, ang interface ng tunnel, at ang partikular na address at port ng endpoint na kailangan ng transport ng tunnel.
Ang eksepsiyon para sa endpoint ay dapat nasa lugar bago umangat ang tunnel, kung hindi ay hindi maabot ng kliyente ng VPN ang server nito. Iyon ang dahilan kung bakit tahasan na pinapayagan ng set ng patakaran ang panlabas na transport sa halip na payagan ang pisikal na interface sa pangkalahatan. Magdagdag din ng mga patakaran sa IPv6 kung may konektibidad na IPv6 ang namespace, dahil ang patakarang IPv4 lamang ay nag-iiwan ng bukas sa kabilang pamilya.
Bahagi rin ng patakaran ang DNS. Kung niresolba ng app ang mga pangalan sa pamamagitan ng resolver na maaabot lamang sa loob ng tunnel, puputulin ng patakaran sa pagtapon ang resolusyon kapag bumaba ang tunnel, at iyon ang tamang pag-uugali para sa kill switch. Magpasya nang sadya kung iyon ang gusto mo.
Subukan ang lifecycle, hindi lang ang pagkadiskonekta
Magpadala ng sariwang hindi nakakapinsalang kahilingan habang malusog ang tunnel, pagkatapos patayin ang proseso ng VPN at magpadala ng isa pa. Ulitin pagkatapos ng paghinto ng container, pagkatapos ng restart at pagkatapos ng muling paglikha. Mahalaga ang sariwang kahilingan dahil ang umiiral na koneksiyon ay maaaring mabuhay sa pagbabago ng patakaran na humaharang sa mga bago.
Huwag umasa sa health check o sa paghahanap ng exit IP bilang mekanismo ng pagharang. Ang check ay nagmamasid sa kalagayan at iniuulat ito; ang patakaran ay kumokontrol sa trapiko. Pagsasama ang dalawa sa iisang deployment, at hindi sila kapalit.
Itala ang mga patakaran upang mabuhay ang pagsubok sa isang update
Isulat ang inaasahang resulta para sa bawat kaso ng pagkabigo sa dokumentasyon ng deployment, kasama ang mga patakarang nagpapatupad nito. Ang talaang iyon ay nagpapahintulot na patakbuhin ang parehong pagsubok pagkatapos ng update ng image o upgrade ng runtime, kapag ang pag-uugali ng namespace o ang mga default na ruta ay maaaring magbago nang walang nag-e-edit ng file ng compose.
Panatilihing hiwalay ang kinakailangang panlabas na landas ng endpoint ng VPN sa walang limitasyong paglabas ng app, at panatilihin ang DNS at IPv6 sa loob ng inilaan na saklaw. Kung pinapayagan ng patakaran ang buong pisikal na interface para sa kaginhawahan, wala na ang kill switch. Inilalarawan ng dokumentasyon ng networking ng Docker ang kaayusan ng ibinabahaging namespace na pinagbabatayan ng patakaran, at iyon ang reperensiyang dapat suriin kapag pinagdududahan ang pag-uugali ng runtime.