VPN-jobber som gjenoppretter hosts-filen sletter senere endringer

En tilkoblingsjobb kopierer Windows-hosts-filen, legger til én privat adresse, og en frakoblingsjobb kopierer den lagrede versjonen tilbake. Det virker i ukevis, og så en ettermiddag når maskinen ikke en intern side som ikke har noe med VPN å gjøre. Gjenopprettingen gjorde nøyaktig det den fikk beskjed om: den la tilbake en fil fra før noen andres endring. Feilen ligger i modellen, ikke i kopikommandoen.

Enhver arbeidsflyt som tar et øyeblikksbilde av en delt fil og senere gjenoppretter den, arver hver endring som gjøres imellom som et tap.

En sikkerhetskopi som gjenopprettes senere er ikke en kopi av nåtiden

Gå gjennom en vanlig sekvens. Jobben lagrer filen og legger til en oppføring for tunnelen. Senere legger en administrator til en urelatert rettelse, og en andre profil legger til sin egen oppføring. Ved frakobling legger gjenopprettingen tilbake det opprinnelige øyeblikksbildet og fjerner både den andre profilens oppføring og administratorens rettelse. Ingen av dem tilhørte VPN, og begge er nå borte.

Ett fast sikkerhetskopifilnavn gjør det verre. En senere tilkoblingshendelse kan kopiere den allerede endrede filen over den angivelige originalen, slik at gjenopprettingsgrunnlaget driver mot hvordan filen så ut ved den siste hendelsen.

Hver hendelse er et varsel, ikke en transaksjon

En hendelsesstyrt jobb er et varsel. En gjentilkobling, en avbrutt avslåing eller en andre profil kan omforme den påkrevde tilstanden mens en tidligere jobb fortsatt skriver. Ingenting serialiserer de to, og ingenting ruller tilbake en halvferdig endring. En hendelsesidentifikator alene sier heller ikke hvilken profil den hører til uten leverandøren og dens data. Å behandle jobben som en transaksjon er forutsetningen som svikter.

Gjentatte tilkoblingshendelser er den andre halvdelen: en tilføyelse uten kontroll lager en andre identisk oppføring, og noen resolvere ser da to svar for ett navn.

Gi hver mapping en eier

Hver linje i hosts-filen mapper et vertsnavn til en adresse og sier ingenting om hvilken tunnel som er oppe. Hvis automatisering er uunngåelig, utpek én eier for mappingene som VPN styrer. Den eieren bør bare oppdatere sine egne oppføringer, bevare urelatert gjeldende innhold, unngå duplikater ved en gjentatt hendelse og avstemme mot tilkoblingene som faktisk er aktive, ikke mot en husket liste.

Når to levende tunneler trenger den samme mappingen, må én frakobling ikke fjerne den mens den andre eieren fortsatt trenger den. Det krever referansetelling eller en uttrykkelig eierregistrering, ikke en boolsk verdi.

En sikkerhetskopi har fortsatt verdi for gjennomgått gjenoppretting. Den bør ikke være den vanlige frakoblingshandlingen, og den bør ikke være den eneste registreringen av hva filen inneholdt.

Når betinget DNS er det egentlige behovet

Hvis det faktiske kravet er et privat navnerom som bare løses opp mens tunnelen er oppe, er hosts feil mekanisme. Windows NRPT kan velge en resolver for et navnerom, og den oppretter ikke adresseoppføringen selv; en resolver må fortsatt svare. Det er et annet design med en annen eier, og det fjerner filredigeringen ved hver overgang helt.

Hvis hosts beholdes med vilje for én fast tjeneste, må du sørge for at adressen forblir nåbar over den tiltenkte ruten og at vertsnavnet forblir stabilt, slik at applikasjonens identitetskontroller fortsetter å virke. Tømming av en DNS-buffer kan ikke reparere en utdatert oppføring som neste oppslag leser igjen.

Test gjentatte tilkoblinger, to samtidige profiler og en frakobling etter en urelatert endring. Resultatet bør være at VPN-ens mapping følger sin eier uten å spole resten av maskinen tilbake.