Detyrat VPN që rikthejnë skedarin hosts fshijnë modifikimet e mëvonshme

Një detyrë lidhjeje kopjon skedarin hosts të Windows, shton një adresë private, dhe një detyrë shkëputjeje kopjon mbrapsht versionin e ruajtur. Funksionon me javë dhe pastaj një pasdite makina nuk arrin një sajt të brendshëm që nuk ka asnjë lidhje me VPN-në. Rikthimi bëri pikërisht atë që iu tha: ktheu një skedar nga përpara modifikimit të dikujt tjetër. Defekti është në model, jo në komandën e kopjimit.

Çdo rrjedhë pune që bën një fotografi të një skedari të përbashkët dhe pastaj e rikthen atë trashëgon çdo ndryshim të bërë në mes si humbje.

Një kopje rezervë e rikthyer më vonë nuk është kopje e tanishmes

Kaloni nëpër një sekuencë të zakonshme. Detyra ruan skedarin dhe shton një zë për tunelin. Më vonë një administrator shton një korrigjim të palidhur, dhe një profil i dytë shton zërin e vet. Në shkëputje rikthimi vendos fotografi në origjinale, duke hequr si zërin e profilit të dytë ashtu edhe korrigjimin e administratorit. Asnjëra nuk i përkiste VPN-së, dhe të dyja tani kanë humbur.

Një emër i vetëm fiks i skedarit të kopjes rezervë e përkeqëson situatën. Një ngjarje lidhjeje e mëvonshme mund të kopjojë skedarin tashmë të ndryshuar mbi origjinalin e supozuar, kështu që baza e rikthimit rrëshqet drejt pamjes që kishte skedari në ngjarjen e fundit.

Çdo ngjarje është një njoftim, jo një transaksion

Një detyrë e nisur nga një ngjarje është një njoftim. Një rilidhje, një mbyllje e ndërprerë ose një profil i dytë mund të riformësojnë gjendjen e kërkuar ndërsa një detyrë e mëparshme po shkruan ende. Asgjë nuk i serializon të dyja, dhe asgjë nuk e kthen mbrapsht një ndryshim gjysmë të përfunduar. Gjithashtu një identifikues i vetëm i ngjarjes nuk thotë se cilit profil i përket pa ofruesin dhe të dhënat e tij. Trajtimi i detyrës si transaksion është supozimi që dështon.

Ngjarjet e përsëritura të lidhjes janë gjysma tjetër: një shtim pa verifikim krijon një zë të dytë identik, dhe atëherë disa zgjidhës shohin dy përgjigje për një emër.

Jepini çdo hartëzimi një pronar

Çdo rresht në skedarin hosts harton një emër hosti në një adresë dhe nuk thotë asgjë se cili tunel është aktiv. Nëse automatizimi është i pashmangshëm, caktoni një pronar për hartëzimet që menaxhohen nga VPN. Ai pronar duhet të përditësojë vetëm zërat e vet, të ruajë përmbajtjen aktuale të palidhur, të shmangë dublikatat në një ngjarje të përsëritur dhe të rakordojë me lidhjet që janë vërtet aktive dhe jo me një listë të mbajtur mend.

Kur dy tunele aktive kanë nevojë për të njëjtin hartëzim, një shkëputje e vetme nuk duhet ta heqë ndërsa pronari tjetër ka ende nevojë për të. Kjo kërkon numërim referencash ose një regjistrim të qartë pronësie, jo një vlerë boolean.

Një kopje rezervë ka ende vlerë për një rikthim të shqyrtuar. Nuk duhet të jetë veprimi normal i shkëputjes, dhe nuk duhet të jetë i vetmi regjistrim i asaj që përmbante skedari.

Kur DNS i kushtëzuar është nevoja e vërtetë

Nëse kërkesa e vërtetë është një hapësirë emrash private që zgjidhet vetëm sa kohë tuneli është aktiv, hosts është mekanizmi i gabuar. Windows NRPT mund të zgjedhë një zgjidhës për një hapësirë emrash, dhe nuk e krijon vetë regjistrimin e adresës; një zgjidhës duhet prapë të përgjigjet. Ky është një dizajn tjetër me një pronar tjetër, dhe e heq plotësisht modifikimin e skedarit në çdo tranzicion.

Nëse hosts mbahet me qëllim për një shërbim të vetëm fiks, sigurohuni që adresa e tij të mbetet e arritshme përmes rrugës së synuar dhe emri i hostit të mbetet i qëndrueshëm, që kontrollet e identitetit të aplikacionit të vazhdojnë të punojnë. Pastrimi i një cache DNS nuk mund të riparojë një zë të vjetruar që kërkimi i radhës do ta lexojë përsëri.

Testoni lidhje të përsëritura, dy profile njëkohësisht dhe një shkëputje pas një modifikimi të palidhur. Rezultati duhet të jetë që hartëzimi i VPN-së ndjek pronarin e vet pa e rrotulluar mbrapsht pjesën tjetër të makinës.