VPN-uppgifter som återställer hosts-filen raderar senare ändringar

En anslutningsuppgift kopierar Windows hosts-fil, lägger till en privat adress, och en frånkopplingsuppgift kopierar tillbaka den sparade versionen. Det fungerar i veckor och sedan en eftermiddag når maskinen inte en intern sida som inte har något med VPN att göra. Återställningen gjorde precis det den blev tillsagd: den lade tillbaka en fil från före någon annans ändring. Felet ligger i modellen, inte i kopieringskommandot.

Varje arbetsflöde som tar en ögonblicksbild av en delad fil och senare återställer den ärver varje ändring som görs däremellan som en förlust.

En säkerhetskopia som återställs senare är inte en kopia av nuet

Gå igenom ett vanligt förlopp. Uppgiften sparar filen och lägger till en post för tunneln. Senare lägger en administratör till en orelaterad rättelse, och en andra profil lägger till sin egen post. Vid frånkoppling lägger återställningen tillbaka den ursprungliga ögonblicksbilden och tar bort både den andra profilens post och administratörens rättelse. Ingen av dem tillhörde VPN, och båda är nu borta.

Ett enda fast säkerhetskopiefilnamn gör det värre. En senare anslutningshändelse kan kopiera den redan ändrade filen över det påstådda originalet, så återställningsbasen glider mot hur filen såg ut vid den senaste händelsen.

Varje händelse är en avisering, inte en transaktion

En händelsestyrd uppgift är en avisering. En återanslutning, en avbruten avstängning eller en andra profil kan omforma det nödvändiga tillståndet medan en tidigare uppgift fortfarande skriver. Inget serialiserar de två, och inget rullar tillbaka en halvfärdig ändring. En händelseidentifierare ensam säger inte heller vilken profil den hör till utan leverantören och dess data. Att behandla uppgiften som en transaktion är antagandet som fallerar.

Upprepade anslutningshändelser är den andra halvan: ett tillägg utan kontroll skapar en andra identisk post, och vissa resolvare ser då två svar för ett namn.

Ge varje mappning en ägare

Varje rad i hosts-filen mappar ett värdnamn till en adress och säger ingenting om vilken tunnel som är uppe. Om automatisering är oundviklig, utse en ägare för de mappningar som VPN hanterar. Den ägaren bör bara uppdatera sina egna poster, bevara orelaterat aktuellt innehåll, undvika dubbletter vid en upprepad händelse och stämma av mot de anslutningar som faktiskt är aktiva och inte mot en ihågkommen lista.

När två levande tunnlar behöver samma mappning får en enda frånkoppling inte ta bort den medan den andra ägaren fortfarande behöver den. Det kräver referensräkning eller en uttrycklig ägarpost, inte ett booleskt värde.

En säkerhetskopia har fortfarande värde för granskad återställning. Den bör inte vara den vanliga frånkopplingsåtgärden, och den bör inte vara den enda anteckningen om vad filen innehöll.

När villkorad DNS är det egentliga behovet

Om det faktiska kravet är ett privat namnområde som bara löses upp medan tunneln är uppe, är hosts fel mekanism. Windows NRPT kan välja en resolvare för ett namnområde, och den skapar inte adressposten själv; en resolvare måste ändå svara. Det är en annan design med en annan ägare, och den tar bort filredigeringen vid varje övergång helt.

Om hosts behålls med avsikt för en enda fast tjänst, se till att dess adress förblir nåbar över den avsedda vägen och att dess värdnamn förblir stabilt så att programmets identitetskontroller fortsätter att fungera. Tömning av en DNS-cache kan inte reparera en inaktuell post som nästa sökning läser igen.

Testa upprepade anslutningar, två samtidiga profiler och en frånkoppling efter en orelaterad ändring. Resultatet bör vara att VPN:s mappning följer sin ägare utan att spola tillbaka resten av maskinen.