VPN-take wat die hosts-lêer herstel, vee latere wysigings uit

’n Koppeltaak kopieer die Windows hosts-lêer, voeg een private adres by, en ’n ontkoppeltaak kopieer die gestoorde weergawe terug. Dit werk weke lank en dan een middag kan die masjien nie ’n interne werf bereik wat niks met die VPN te doen het nie. Die herstel het presies gedoen wat aan hom gesê is: dit het ’n lêer van voor iemand anders se wysiging teruggesit. Die fout lê in die model, nie in die kopieeropdrag nie.

Enige werksvloei wat ’n gedeelde lêer vasvang en later herstel, erf elke wysiging wat intussen gemaak is as ’n verlies.

’n Rugsteun wat later herstel word, is nie ’n rugsteun van nou nie

Stap deur ’n gewone reeks. Die taak stoor die lêer en voeg ’n inskrywing vir die tonnel by. Later voeg ’n administrateur ’n onverwante regstelling by, en ’n tweede profiel voeg sy eie inskrywing by. By ontkoppeling sit die herstel die oorspronklike oomblikopname terug en verwyder sowel die tweede profiel se inskrywing as die administrateur se regstelling. Nie een van hulle het aan die VPN behoort nie, en albei is nou weg.

’n Enkele vaste rugsteunlêernaam maak dit erger. ’n Latere koppelgebeurtenis kan die reeds gewysigde lêer oor die vermeende oorspronklike kopieer, sodat die herstelbasis na die lêer se voorkoms by die laaste gebeurtenis wegdryf.

Elke gebeurtenis is ’n kennisgewing, nie ’n transaksie nie

’n Gebeurtenisgedrewe taak is ’n kennisgewing. ’n Herverbinding, ’n onderbroke afskakeling of ’n tweede profiel kan die vereiste toestand hervorm terwyl ’n vroeëre taak nog besig is om te skryf. Niks serialiseer die twee nie, en niks rol ’n halfvoltooide wysiging terug nie. ’n Gebeurtenisidentifiseerder alleen sê ook nie by watter profiel dit hoort sonder die verskaffer en sy data nie. Om die taak as ’n transaksie te behandel, is die aanname wat faal.

Herhaalde koppelgebeurtenisse is die ander helfte: ’n byvoeging sonder ’n kontrole skep ’n tweede identiese inskrywing, en sommige oplossers sien dan twee antwoorde vir een naam.

Gee elke kartering ’n eienaar

Elke reël in die hosts-lêer karteer ’n gasheernaam na ’n adres en sê niks oor watter tonnel op is nie. As outomatisering onvermydelik is, wys een eienaar toe vir die VPN-bestuurde karterings. Daardie eienaar moet net sy eie inskrywings opdateer, onverwante huidige inhoud bewaar, duplikate by ’n herhaalde gebeurtenis vermy, en met die verbindings wat werklik aktief is rekonsilieer eerder as met ’n onthou lys.

Wanneer twee lewende tonnels dieselfde kartering nodig het, mag ’n enkele ontkoppeling dit nie verwyder terwyl die ander eienaar dit nog nodig het nie. Dit vereis verwysingstelling of ’n eksplisiete eienaarskaprekord, nie ’n boole nie.

’n Rugsteun het steeds waarde vir hersiene herstel. Dit moet nie die normale ontkoppelaksie wees nie, en dit moet nie die enigste rekord wees van wat die lêer bevat het nie.

Wanneer voorwaardelike DNS die werklike behoefte is

As die werklike vereiste ’n private naamruimte is wat net oplos terwyl die tonnel op is, is hosts die verkeerde meganisme. Windows NRPT kan ’n oplosser vir ’n naamruimte kies, en dit skep nie self die adresrekord nie; ’n oplosser moet steeds antwoord. Dit is ’n ander ontwerp met ’n ander eienaar, en dit verwyder die lêerbewerking per oorgang heeltemal.

As hosts doelbewus vir een vaste diens behou word, maak seker sy adres bly bereikbaar oor die beoogde roete en sy gasheernaam bly stabiel sodat toepassingsidentiteitskontroles bly werk. Die uitvee van ’n DNS-kas kan nie ’n verouderde inskrywing herstel wat die volgende opsoek weer lees nie.

Toets herhaalde verbindings, twee gelyktydige profiele en ’n ontkoppeling ná ’n onverwante wysiging. Die resultaat moet wees dat die VPN se kartering sy eienaar volg sonder om die res van die masjien terug te spoel.