Sarcinile VPN care restaurează fișierul hosts șterg modificările ulterioare

O sarcină de conectare copiază fișierul hosts din Windows, adaugă o adresă privată, iar o sarcină de deconectare copiază versiunea salvată înapoi. Funcționează săptămâni întregi, iar apoi într-o după-amiază calculatorul nu mai ajunge la un site intern care nu are nimic de-a face cu VPN-ul. Restaurarea a făcut exact ce i s-a spus: a pus înapoi un fișier de dinaintea modificării altcuiva. Defectul este în model, nu în comanda de copiere.

Orice flux de lucru care face o copie a unui fișier partajat și îl restaurează mai târziu moștenește fiecare modificare făcută între timp ca pierdere.

O copie de siguranță restaurată mai târziu nu este o copie a prezentului

Parcurgeți o secvență obișnuită. Sarcina salvează fișierul și adaugă o intrare pentru tunel. Mai târziu un administrator adaugă o corectură fără legătură, iar un al doilea profil adaugă propria intrare. La deconectare, restaurarea pune înapoi copia originală, eliminând atât intrarea celui de-al doilea profil, cât și corectura administratorului. Niciuna nu aparținea VPN-ului, iar ambele au dispărut acum.

Un singur nume fix de fișier de backup înrăutățește situația. Un eveniment de conectare ulterior poate copia fișierul deja modificat peste presupusul original, astfel încât baza de recuperare derivează spre felul în care arăta fișierul la ultimul eveniment.

Fiecare eveniment este o notificare, nu o tranzacție

O sarcină declanșată de un eveniment este o notificare. O reconectare, o oprire întreruptă sau un al doilea profil pot remodela starea necesară în timp ce o sarcină anterioară încă scrie. Nimic nu le serializează pe cele două, și nimic nu anulează o modificare pe jumătate terminată. De asemenea, un identificator de eveniment singur nu spune cărui profil îi aparține fără furnizor și datele acestuia. Tratarea sarcinii ca o tranzacție este presupunerea care eșuează.

Evenimentele de conectare repetate sunt cealaltă jumătate: o adăugare fără verificare creează o a doua intrare identică, iar unii resolvers văd atunci două răspunsuri pentru un singur nume.

Dați fiecărei mapări un proprietar

Fiecare linie din fișierul hosts asociază un nume de gazdă unei adrese și nu spune nimic despre ce tunel este activ. Dacă automatizarea este inevitabilă, desemnați un singur proprietar pentru mapările gestionate de VPN. Acel proprietar ar trebui să actualizeze doar propriile intrări, să păstreze conținutul actual fără legătură, să evite duplicatele la un eveniment repetat și să se reconcilieze cu conexiunile care sunt cu adevărat active, nu cu o listă ținută minte.

Când două tuneluri active au nevoie de aceeași mapare, o singură deconectare nu trebuie să o elimine cât timp celălalt proprietar încă are nevoie de ea. Asta cere numărare de referințe sau o înregistrare explicită a proprietății, nu o valoare booleană.

O copie de siguranță are încă valoare pentru o recuperare revizuită. Nu ar trebui să fie acțiunea normală de deconectare și nu ar trebui să fie singura înregistrare a ceea ce conținea fișierul.

Când DNS-ul condiționat este nevoia reală

Dacă cerința reală este un spațiu de nume privat care se rezolvă doar cât timp tunelul este activ, hosts este mecanismul greșit. Windows NRPT poate alege un resolver pentru un spațiu de nume și nu creează ea însăși înregistrarea de adresă; un resolver tot trebuie să răspundă. Acesta este un alt proiect cu alt proprietar și elimină complet editarea fișierului la fiecare tranziție.

Dacă hosts este păstrat intenționat pentru un singur serviciu fix, asigurați-vă că adresa lui rămâne accesibilă pe ruta prevăzută și că numele de gazdă rămâne stabil, astfel încât verificările de identitate ale aplicației să continue să funcționeze. Golirea unui cache DNS nu poate repara o intrare învechită pe care căutarea următoare o va citi din nou.

Testați conectări repetate, două profiluri simultane și o deconectare după o modificare fără legătură. Rezultatul ar trebui să fie că maparea VPN-ului urmează proprietarul ei fără a derula restul mașinii înapoi.