Binubura ng mga VPN task na nagbabalik ng hosts file ang mga susunod na pag-edit

Kinokopya ng task sa pagkonekta ang hosts file ng Windows, nagdaragdag ng isang pribadong address, at ang task sa paghihiwalay ay kinokopya pabalik ang naka-save na bersyon. Gumagana ito nang maraming linggo at pagkatapos isang hapon ay hindi na maabot ng makina ang isang panloob na site na walang kaugnayan sa VPN. Ginawa ng pagbabalik nang eksakto ang sinabi dito: ibinalik nito ang file mula bago ang pag-edit ng ibang tao. Ang sira ay nasa modelo, hindi sa utos ng pagkopya.

Ang anumang workflow na kumukuha ng snapshot ng shared file at pagkatapos ay ibinabalik ito ay nagmamana ng bawat pagbabagong ginawa sa gitna bilang pagkawala.

Ang backup na ibinalik mamaya ay hindi backup ng ngayon

Sundan ang isang karaniwang pagkakasunod-sunod. Sine-save ng task ang file at nagdaragdag ng entry para sa tunnel. Maya-maya ay nagdaragdag ang administrator ng walang kaugnayang pagwawasto, at ang pangalawang profile ay nagdaragdag ng sarili nitong entry. Sa paghihiwalay ay ibinabalik ng restore ang orihinal na snapshot, inaalis kapwa ang entry ng pangalawang profile at ang pagwawasto ng administrator. Wala sa dalawa ang pag-aari ng VPN, at ngayon ay wala na ang dalawa.

Isang fixed backup filename lang ang nagpapalala. Ang susunod na kaganapan sa pagkonekta ay maaaring kopyahin ang na-edit nang file sa ibabaw ng sinasabing orihinal, kaya ang basehan ng pagbawi ay dumadausdos patungo sa itsura ng file sa huling kaganapan.

Bawat kaganapan ay abiso, hindi transaksyon

Ang task na pinapagana ng kaganapan ay isang abiso. Ang muling pagkonekta, isang putol na pagsasara o isang pangalawang profile ay maaaring maghubog muli ng kinakailangang estado habang ang naunang task ay nagsusulat pa. Walang nagse-serye sa dalawa, at walang nagbabalik ng kalahating tapos na pagbabago. Bukod dito, ang identifier ng kaganapan lamang ay hindi nagsasabi kung aling profile ito nabibilang kung wala ang provider at ang data nito. Ang pagtrato sa task bilang transaksyon ang palagay na nabibigo.

Ang paulit-ulit na kaganapan sa pagkonekta ang kabilang kalahati: ang pagdaragdag nang walang pagsusuri ay lumilikha ng pangalawang magkatulad na entry, at may mga resolver na nakakakita ng dalawang sagot para sa isang pangalan.

Bigyan ng may-ari ang bawat mapping

Bawat linya sa hosts file ay nagmamapa ng hostname sa isang address at walang sinasabi tungkol sa kung aling tunnel ang bukas. Kung hindi maiiwasan ang automation, magtalaga ng isang may-ari para sa mga mapping na pinamamahalaan ng VPN. Dapat i-update lamang ng may-ari na iyon ang sarili nitong mga entry, panatilihin ang walang kaugnayang kasalukuyang nilalaman, iwasan ang mga duplikado sa paulit-ulit na kaganapan, at makipagkasundo sa mga koneksyong talagang aktibo at hindi sa isang listahang naaalala.

Kapag kailangan ng dalawang buhay na tunnel ang parehong mapping, hindi ito dapat alisin ng isang paghihiwalay habang kailangan pa ito ng kabilang may-ari. Nangangailangan ito ng pagbilang ng reperensya o malinaw na talaan ng pagmamay-ari, hindi isang boolean.

May halaga pa rin ang backup para sa sinuring pagbawi. Hindi ito dapat maging karaniwang aksyon sa paghihiwalay, at hindi ito dapat maging tanging talaan ng laman ng file.

Kapag ang kondisyonal na DNS ang tunay na pangangailangan

Kung ang tunay na pangangailangan ay isang pribadong namespace na lumulutas lamang habang bukas ang tunnel, hosts ang maling mekanismo. Maaaring pumili ang Windows NRPT ng resolver para sa isang namespace, at hindi nito mismo nililikha ang address record; kailangan pa ring sumagot ng resolver. Iba itong disenyo na may ibang may-ari, at tuluyan nitong inaalis ang pag-edit ng file sa bawat paglipat.

Kung sadyang pinapanatili ang hosts para sa isang fixed na serbisyo, tiyakin na ang address nito ay nananatiling maabot sa nilalayong ruta at ang hostname nito ay nananatiling stable para patuloy na gumana ang mga pagsusuri ng pagkakakilanlan ng application. Ang paglilinis ng cache ng DNS ay hindi makakapag-ayos ng lumang entry na muling babasahin ng susunod na paghahanap.

Subukan ang paulit-ulit na pagkonekta, dalawang magkasabay na profile at isang paghihiwalay pagkatapos ng walang kaugnayang pag-edit. Dapat ang resulta ay ang mapping ng VPN ay sumusunod sa may-ari nito nang hindi binabaliktad ang natitirang bahagi ng makina.