Sino ang may-ari ng address, ruta, DNS at firewall sa isang VPN Linux?
Ang VPN Linux ay nangangailangan ng isang awtoridad bawat bagay: device, address, ruta, DNS, firewall. Isulat ang mapa, pagkatapos ay tukuyin kung ano ang ibinabalik ng boot, muling pagkonekta at pagtatanggal.
Dalawang script na nag-aaway sa parehong ruta ang karaniwang anyo ng problemang VPN Linux na naitala bilang bug sa rutang. Isang bahagi ang gumagawa ng tunnel device, isa pa ang nagdaragdag ng default na ruta, ang pangatlo ay nagsusulat muli ng configuration ng resolver, at ang pang-apat ay nagre-reload ng mga patakaran ng firewall. Sinuman sa kanila ay maaaring magpawalang-bisa sa gawa ng iba, at ang panalo ay ang huling tumakbo. Ang tanong na dapat sagutin ay hindi kung aling pakete ang i-install, kundi kung aling bahagi ang may awtoridad sa bawat piraso ng estado.
Isulat ang mapang iyon nang isang beses, at ang karamihan ng pagkabigo sa muling pagkonekta ay titigil na maging misteryoso. Apat na bagay ang mahalaga: ang device at ang mga address nito, ang mga ruta at alituntunin sa patakaran, ang configuration ng DNS at ang firewall.
Ang device at ang mga address nito
Ang tunnel device ay ginagawa ng isang tagapamahala na nakakaalam ng profile, o ng isang daemon na sinimulan ng isang tao nang manu-mano. Pareho silang gumagana nang mag-isa; ang pagsasama sa kanila ay hindi. Kung ang NetworkManager ang may-ari ng profile, hayaan din itong magmay-ari ng device, at huwag magsimula ng OpenVPN na hindi pinamamahalaan laban sa parehong pangalan ng tunnel.
Itala kung sino ang nag-aalis ng device kapag nagtatapos ang session. Ang device na mas mahaba ang buhay kaysa sa session nito ang pinakakaraniwang pinagmumulan ng mga lumang address at ng pagkalito na sumusunod.
Mga ruta at alituntunin sa patakaran
Sa mga ruta mismo nagdudulot ng nakikitang pinsala ang mga salungatan sa pagmamay-ari. Ang tagapamahala ng koneksyon ay naglalagay ng default na ruta para sa tunnel at mas partikular na ruta para sa malayong network; pagkatapos ay nagdaragdag ang isang manu-manong isinulat na script ng sarili nitong default na may ibang sukatan at tahimik na nananalo o natatalo depende sa oras. Magpasya kung aling mga entry ang nakatali sa koneksyon, alin ang permanenteng patakaran, at aling bahagi ang nagre-refresh sa kanila pagkatapos ng muling pagkonekta. Pagkatapos ay panatilihin ang iba pang bahagi sa labas ng talahanayang iyon.
Ang mga alituntunin sa patakaran ay karapat-dapat sa parehong kalinawan, dahil ang isang patakaran na tumuturo sa isang talahanayang walang pumupuno ay gumagawa ng itim na butas na eksaktong kamukha ng isang patay na tunnel. Kung may patakarang umiiral upang pilitin ang trapiko sa isang lugar, ang talahanayang pinipili nito ay dapat panatilihin ng parehong may-ari.
Ang DNS ay laging hiwalay na may-ari
Ang resolver daemon ay tumatakbo bilang sariling proseso sa ilalim ng sariling pagkakakilanlan, kaya hindi nito namamana ang mga desisyon sa ruta ng tunnel nang hindi sinasadya. Kapag nagtutulak ang VPN ng mga DNS server, may dapat magsalin nito sa configuration kada link na iginagalang ng resolver, at may dapat mag-alis nito pagkatapos.
Ang mito dito ay ang pagsulat ng name server sa profile ay nagbabago kung saan pumupunta ang mga query. Binabago nito ang sinasabi sa resolver, hindi kung aling socket ang ginagamit ng resolver upstream. Subukan gamit ang isang query at isang paghahanap ng ruta sa halip na magtiwala sa file.
Ang estado ng firewall, at kung sino ang nagbabalik nito
Ang mga patakaran ng firewall ang pinakamadalas i-overwrite na bagay sa isang VPN host. Ang tagapamahala ay maaaring magdagdag ng NAT o forwarding na patakaran bawat koneksyon, habang ang isang serbisyo ng firewall sa boot ay nagre-reload ng naka-save na set ng patakaran at binubura ang mga ito. Pumili ng isang awtoridad para sa patakaran at gawing mamimili nito ang isa, o tanggapin na ang isang restart ay tahimik na nagbabago ng pag-uugali. Ang mga eksepsiyon na nakatali sa koneksyon ay nabibilang sa isang file na nila-load ng parehong may-ari, hindi sa isang utos na iptables na tina-type habang nag-aayos ng problema.
Kung ang mga patakaran ay dapat mabuhay pagkatapos ng muling pagkonekta, sabihin ito nang malinaw. Kung hindi, sabihin din, dahil ipagpapalagay ng susunod na inhinyero ang mas maginhawang sagot.
Siklo ng buhay: boot, muling pagkonekta, pagtatanggal
Bigyan ng may-ari ang bawat isa sa tatlong sandaling iyon. Sa boot, magpasya kung ano ang naghahanda ng mga paunang kundisyon at sa anong pagkakasunod-sunod. Sa malambot na restart, tandaan na ang device ay maaaring mabuhay habang ang estado ng session ay hindi, kaya ang isang validator ay dapat tumakbo sa halip na isang tagalikha. Sa pagtatanggal, alisin lamang ang ginawa ng koneksyong ito, dahil ang pag-reset sa bawat ruta o paglilinis sa buong firewall ay hindi katulad ng pagretiro sa isang tunnel.
Para sa pagmamasid, ipinapakita ng ip monitor link address route ang mga pagbabago sa kernel habang nangyayari, ngunit nag-uulat ito ng mga kaganapan sa halip na intensyon: ang isang tinanggal na ruta ay walang sinasabi tungkol sa kung aling proseso ang nagtanggal nito. Ipares ito sa mapa ng pagmamay-ari, at ang nakalilitong pagsasara ay magiging maikling listahan ng mga kandidato.
Ang mga eksepsiyon ay may gastos din. Ang pagmamarka sa isang buong klase ng device bilang hindi pinamamahalaan upang makatakas sa salungatan ay nagbibigay ng estadong iyon sa walang sinuman, na isang desisyon at hindi isang pagwawasto.