VPN-oppgåver som gjenopprettar hosts-fila slettar seinare endringar

Ei tilkoplingsoppgåve kopierer Windows hosts-fil, legg til éin privat adresse, og ei fråkoplingsoppgåve kopierer den lagra versjonen tilbake. Det verkar i veker, og så ein ettermiddag når maskinen ikkje ei intern side som ikkje har noko med VPN å gjere. Gjenopprettinga gjorde nøyaktig det ho fekk beskjed om: ho la tilbake ei fil frå før endringa til nokon andre. Feilen ligg i modellen, ikkje i kopieringskommandoen.

Kvar arbeidsflyt som tek eit augeblinksbilde av ei delt fil og seinare gjenopprettar ho, arvar kvar endring som blir gjord imellom som eit tap.

Ein sikkerheitskopi som blir gjenoppretta seinare er ikkje ein kopi av notida

Gå gjennom ein vanleg sekvens. Oppgåva lagrar fila og legg til ei oppføring for tunnelen. Seinare legg ein administrator til ei urelatert retting, og ein andre profil legg til si eiga oppføring. Ved fråkopling legg gjenopprettinga tilbake det opphavlege augeblinksbildet og fjernar både oppføringa til den andre profilen og rettinga til administratoren. Ingen av dei høyrde til VPN, og begge er no borte.

Eitt fast sikkerheitskopifilnamn gjer det verre. Ei seinare tilkoplingshending kan kopiere den allereie endra fila over den påståtte originalen, slik at gjenopprettingsgrunnlaget driv mot korleis fila såg ut ved den siste hendinga.

Kvar hending er eit varsel, ikkje ein transaksjon

Ei hendingsstyrt oppgåve er eit varsel. Ei gjentilkopling, ei avbroten avslåing eller ein andre profil kan forme om den påkravde tilstanden medan ei tidlegare oppgåve framleis skriv. Ingenting serialiserer dei to, og ingenting rullar tilbake ei halvferdig endring. Ein hendingsidentifikator åleine seier heller ikkje kva profil han høyrer til utan leverandøren og dataa hans. Å handsame oppgåva som ein transaksjon er føresetnaden som sviktar.

Gjentekne tilkoplingshendingar er den andre halvdelen: eit tillegg utan kontroll lagar ei andre identisk oppføring, og nokre resolvarar ser då to svar for eitt namn.

Gi kvar mapping ein eigar

Kvar linje i hosts-fila knyter eit vertsnamn til ei adresse og seier ingenting om kva tunnel som er oppe. Viss automatisering er uunngåeleg, peik ut éin eigar for mappingane som VPN styrer. Den eigaren bør berre oppdatere sine eigne oppføringar, ta vare på urelatert gjeldande innhald, unngå duplikat ved ei gjenteken hending og stemme av mot tilkoplingane som faktisk er aktive, ikkje mot ei hugsa liste.

Når to levande tunnelar treng den same mappinga, må éi fråkopling ikkje fjerne ho medan den andre eigaren framleis treng ho. Det krev referanseteljing eller ein uttrykkeleg eigarregistrering, ikkje ein boolsk verdi.

Ein sikkerheitskopi har framleis verdi for gjennomgått gjenoppretting. Ho bør ikkje vere den vanlege fråkoplinga, og ho bør ikkje vere den einaste registreringa av kva fila inneheldt.

Når vilkårsbunde DNS er det eigentlege behovet

Viss det faktiske kravet er eit privat namnerom som berre blir løyst opp medan tunnelen er oppe, er hosts feil mekanisme. Windows NRPT kan velje ein resolvar for eit namnerom, og ho opprettar ikkje adresseoppføringa sjølv; ein resolvar må framleis svare. Det er eit anna design med ein annan eigar, og det fjernar filredigeringa ved kvar overgang heilt.

Viss hosts blir halde ved med vilje for éin fast teneste, må du syte for at adressa hennar er nåbar over den tiltenkte ruta og at vertsnamnet held seg stabilt, slik at identitetskontrollane til programmet held fram med å verke. Tømming av ein DNS-buffer kan ikkje reparere ei utdatert oppføring som neste oppslag les igjen.

Test gjentekne tilkoplingar, to samtidige profilar og ei fråkopling etter ei urelatert endring. Resultatet bør vere at mappinga til VPN følgjer eigaren sin utan å spole resten av maskinen tilbake.