VPN-opgaver, der gendanner hosts-filen, sletter senere ændringer

En forbindelsesopgave kopierer Windows’ hosts-fil, tilføjer én privat adresse, og en afbrydelsesopgave kopierer den gemte version tilbage. Det virker i uger, og så en eftermiddag kan maskinen ikke nå et internt websted, som ikke har noget med VPN at gøre. Gendannelsen gjorde præcis, hvad den fik besked på: den lagde en fil tilbage fra før en andens ændring. Fejlen ligger i modellen, ikke i kopikommandoen.

Enhver arbejdsgang, der tager et øjebliksbillede af en delt fil og senere gendanner den, arver enhver ændring lavet imellem som et tab.

En sikkerhedskopi, der gendannes senere, er ikke en kopi af nu

Gå gennem et almindeligt forløb. Opgaven gemmer filen og tilføjer en post til tunnelen. Senere tilføjer en administrator en urelateret rettelse, og en anden profil tilføjer sin egen post. Ved afbrydelse lægger gendannelsen det oprindelige øjebliksbillede tilbage og fjerner både den anden profils post og administratorens rettelse. Ingen af dem hørte til VPN, og begge er nu væk.

Et enkelt fast sikkerhedskopifilnavn gør det værre. En senere forbindelseshændelse kan kopiere den allerede ændrede fil over den formodede original, så gendannelsesgrundlaget glider mod den filtilstand, der var ved den sidste hændelse.

Hver hændelse er en notifikation, ikke en transaktion

En hændelsesstyret opgave er en notifikation. En genforbindelse, en afbrudt nedlukning eller en anden profil kan omforme den krævede tilstand, mens en tidligere opgave stadig skriver. Intet serialiserer de to, og intet ruller en halvfærdig ændring tilbage. En hændelsesidentifikator alene siger heller ikke, hvilken profil den hører til uden udbyderen og dennes data. At behandle opgaven som en transaktion er den antagelse, der fejler.

Gentagne forbindelseshændelser er den anden halvdel: en tilføjelse uden kontrol skaber en anden identisk post, og nogle resolvere ser så to svar for ét navn.

Giv hver mapping en ejer

Hver linje i hosts-filen mapper et værtsnavn til en adresse og siger intet om, hvilken tunnel der er oppe. Hvis automatisering er uundgåelig, udpeg én ejer til de VPN-styrede mappinger. Den ejer bør kun opdatere sine egne poster, bevare urelateret aktuelt indhold, undgå dubletter ved en gentagen hændelse og afstemme mod de forbindelser, der faktisk er aktive, i stedet for mod en husket liste.

Når to aktive tunneler har brug for den samme mapping, må én afbrydelse ikke fjerne den, mens den anden ejer stadig har brug for den. Det kræver referencetælling eller en eksplicit ejerregistrering, ikke en boolean.

En sikkerhedskopi har stadig værdi til gennemset gendannelse. Den bør ikke være den normale afbrydelseshandling, og den bør ikke være den eneste registrering af, hvad filen indeholdt.

Når betinget DNS er det reelle behov

Hvis det faktiske krav er et privat navnerum, der kun opløses, mens tunnelen er oppe, er hosts den forkerte mekanisme. Windows NRPT kan vælge en resolver til et navnerum, og den opretter ikke selv adresseposten; en resolver skal stadig svare. Det er et andet design med en anden ejer, og det fjerner filredigeringen ved hver overgang helt.

Hvis hosts bevares med vilje til én fast tjeneste, skal du sikre, at dens adresse forbliver nåbar via den tilsigtede rute, og at dens værtsnavn forbliver stabilt, så applikationens identitetskontroller bliver ved med at virke. Rydning af en DNS-cache kan ikke reparere en forældet post, som det næste opslag læser igen.

Test gentagne forbindelser, to samtidige profiler og en afbrydelse efter en urelateret ændring. Resultatet bør være, at VPN’ens mapping følger sin ejer uden at spole resten af maskinen tilbage.