Paano i-lock ang labasan ng Linux para walang tumagas kapag bumagsak ang VPN

Isipin ang isang media box sa home uplink na dapat makarating sa internet sa pamamagitan lamang ng tunnel. Kapag bumagsak ang tunnel, dapat huminto ang application sa halip na tahimik na magpatuloy sa physical interface. Ang pagkuha ng ganoong pag-uugali ay problema ng firewall at hindi ng routing, at mahalaga ang pagkakaiba dahil ang ruta ay maaaring palitan ng restart ng daemon habang ang filter ay nananatili kung saan mo ito inilagay. Ang sumusunod ay kung paano talaga nagpapasya ang landas ng packet, at pagkatapos ay kung paano limitahan ang mga eksepsiyon na nagpapanatili sa tunnel na muling kumonekta.

Ang lokal na output ay ibang hook kaysa sa forwarding

Ang packet na lumalabas mula sa application sa makina ay dumadaan sa output hook; ang packet na irinuruta ng makina para sa ibang host ay dumadaan sa forwarding. Ang patakarang tumutukoy lamang sa forward ay nililimitahan ang pangalawa at iniiwang bukas na bukas ang una, kaya napakaraming lock sa labasan ang mukhang tama at wala namang ginagawa. Ang pagtutugma ng interface ay kabilang sa parehong tuntunin: pinapayagan ng oifname "tun0" accept ang trapikong na-iruta nang labas sa tunnel. Nananatili ring magkahiwalay na desisyon ang routing at filtering, kaya maaaring may rutang uplink habang tinatanggihan ng filter ang packet. Sa paghihiwalay na iyon ka umaasa.

Ang gateway na nagpapa-forward para sa ibang device ay kailangan ang dalawang hook. Ang pag-lock lamang sa output ay pinoprotektahan ang makina mismo at hinahayaang malayang tumagas ang bawat kliyente sa ibaba.

Isulat ang listahan ng eksepsiyon mula sa endpoint pakanluran

Magsimula sa endpoint ng tunnel: isang destinasyong address o maliit na aprubadong set, ang transport protocol at ang destinasyong port, halimbawa udp dport 1194 ip daddr 203.0.113.7 accept. Kung nire-resolve ng kliyente ang hostname, kailangan ng paunang DNS exchange ang sarili nitong tuntunin na limitado sa resolver at sa port 53, hindi isang pangkalahatang permit sa address ng resolver na iyon. Dapat pangalanan ng bawat eksepsiyon ang dahilan kung bakit ito umiiral. Ang permiso para sa lahat ng UDP traffic papunta sa VPN port ay sumasaklaw nang higit pa sa nag-iisang authenticated service na nasa isip mo.

Ang paunang resolution ang lugar kung saan karaniwang nabubulok ang mga lock. Ang set ng address na nire-refresh sa timer ay kailangan ng tinukoy na pag-uugali kapag nabigo ang refresh, at ang pag-uugaling iyon ay hindi maaaring buksan ang link hanggang magtagumpay ito. Mag-refresh sa pamamagitan ng tunnel habang nakatayo ang tunnel, at kung hindi ay bumalik sa huling kilalang malusog na endpoint.

Ang lokal na administrasyon ay kailangan ng parehong pagtrato. Ang management subnet ay hindi mapagkakatiwalaan dahil lamang pribado ang mga address nito, at ang tuntuning nagtitiwala rito ay nag-aanyaya ng ikalawang landas sa paligid ng lock.

Ang pagtutugma ng interface ay hindi patunay ng malusog na tunnel

Ang mga tuntuning tumatanggap sa lahat ng lumalabas sa tun0 ay ipinapalagay na ang packet sa interface na iyon ay galing sa tunnel. Ang mga pangalan ng interface ay muling nililikha, at ang pangalan ay hindi cryptographic identity. Maaaring wala na rin ang peer habang nananatiling nakatayo ang interface, na ginagawang napaka-kumbinsing walang-ginagawa ang tuntunin.

Ang connection tracking ay nagdaragdag ng kaugnay na bitag. Ang malawak na tuntunin para sa established connections ay inuulit ang permiso na nakuha ng isang flow kanina, kaya ang session na nagsimula bago bumagsak ang tunnel ay nagpapatuloy pagkatapos. Limitahan ang stateful acceptance sa mga interface at address na talagang tinutukoy mo, o nakagawa ka ng lock na nagbubukas sa sarili nito. Ang input at output rules ay sumasagot din sa magkaibang tanong, at ang pagpapalakas ng isa habang binabalewala ang isa ay nag-iiwan sa makina na maabot sa direksiyong hindi mo isinaalang-alang.

Ano ang nakakaligtas sa pag-crash ng daemon

Ang filter na inilalagay ng script na tumatakbo pagkatapos umangat ang tunnel ay nawawala kasama ng tunnel, sa eksaktong sandaling kailangan ito. I-load ang lock sa boot at hayaang pangasiwaan ng daemon ang mga eksepsiyon nito lamang.

Ang pagbura ng default route ay hindi rin kapalit. Ang ruta ay state na pag-aari at muling isinusulat ng daemon, at ang pag-alis nito ay maaaring mag-alis ng landas na kailangan para muling kumonekta. Ang IPv6 ay kailangan ng sariling plano, dahil ang neighbor discovery at router advertisements ay link services na dapat patuloy na gumana habang naka-block ang ordinaryong trapiko. Ang DHCP ay kabilang sa parehong kategorya. Isulat ang mga ito bilang eksepsiyon na may layunin, sa halip na matuklasan ang mga ito mamaya bilang outages.

Landas ng pagbangon bago ang deployment

Subukan ang lock sa paraang mabibigo ito: mag-boot na walang tunnel, patayin ang daemon, palitan ang endpoint at muling kumonekta. Dapat ihinto ng bawat kaso ang mga application at iwanang gumagana ang recovery channel. Gawin ito mula sa console, dahil ang remote shell ang session na pinakamalamang na ma-lock out ng sarili mong tuntunin.

Pagkatapos ay tingnan kung saan pa nakakaabot ang ordinaryong application, gamit ang hindi mapaminsalang destinasyon at kahilingang maaari mong i-verify. Ang resultang gusto mo ay pagtanggi sa uplink at tagumpay sa pamamagitan ng tunnel, hindi isang malabong timeout na maaaring mangahulugan ng alinman sa dalawa. Panatilihin ang rule set sa ilalim ng parehong may-ari ng natitirang bahagi ng firewall, sa halip na palitan ang buong table mula sa shell script. Ang patakarang kayang bigyang-katwiran ng bawat permiso ang sarili nito ay mas mahalaga kaysa sa mahabang rule set na walang makapagpapaliwanag.