VPN-taken die het hosts-bestand herstellen, wissen latere bewerkingen

Een verbindingstaak kopieert het Windows hosts-bestand, voegt één privéadres toe, en een verbrekingstaak kopieert de opgeslagen versie terug. Het werkt wekenlang en dan kan de machine op een middag een interne site niet bereiken die niets met de VPN te maken heeft. De herstelling deed precies wat haar was opgedragen: ze zette een bestand terug van vóór iemand anders zijn bewerking. De fout zit in het model, niet in het kopieercommando.

Elke werkwijze die een gedeeld bestand vastlegt en later herstelt, erft elke tussentijdse wijziging als verlies.

Een later herstelde back-up is geen back-up van nu

Loop een gewone reeks door. De taak slaat het bestand op en voegt een regel voor de tunnel toe. Later voegt een beheerder een losse correctie toe, en een tweede profiel voegt zijn eigen regel toe. Bij verbreken zet de herstelling de oorspronkelijke momentopname terug en verwijdert zowel de regel van het tweede profiel als de correctie van de beheerder. Geen van beide hoorde bij de VPN, en beide zijn nu weg.

Eén vaste back-upbestandsnaam maakt het erger. Een latere verbindingsgebeurtenis kan het al gewijzigde bestand over het vermeende origineel kopiëren, waardoor de herstelbasis afdrijft naar hoe het bestand er bij de laatste gebeurtenis uitzag.

Elke gebeurtenis is een melding, geen transactie

Een door een gebeurtenis gestarte taak is een melding. Een herverbinding, een afgebroken afsluiting of een tweede profiel kunnen de vereiste toestand hervormen terwijl een eerdere taak nog aan het schrijven is. Niets serialiseert de twee, en niets draait een half afgeronde wijziging terug. Een gebeurtenisidentificatie alleen zegt ook niet bij welk profiel ze hoort zonder de provider en zijn gegevens. De taak als transactie behandelen is de aanname die faalt.

Herhaalde verbindingsgebeurtenissen zijn de andere helft: een toevoeging zonder controle maakt een tweede identieke regel, en sommige resolvers zien dan twee antwoorden voor één naam.

Geef elke toewijzing een eigenaar

Elke regel in het hosts-bestand koppelt een hostnaam aan een adres en zegt niets over welke tunnel actief is. Als automatisering onvermijdelijk is, wijs dan één eigenaar aan voor de door de VPN beheerde toewijzingen. Die eigenaar hoort alleen zijn eigen regels bij te werken, niet-verwante huidige inhoud te bewaren, duplicaten bij een herhaalde gebeurtenis te vermijden en af te stemmen op de verbindingen die werkelijk actief zijn en niet op een onthouden lijst.

Wanneer twee actieve tunnels dezelfde toewijzing nodig hebben, mag één verbreking die niet verwijderen terwijl de andere eigenaar ze nog nodig heeft. Dat vereist referentietelling of een expliciete eigendomsregistratie, geen boolean.

Een back-up heeft nog waarde voor een nagekeken herstel. Ze hoort niet de normale verbrekingsactie te zijn, en ze hoort niet de enige registratie te zijn van wat het bestand bevatte.

Wanneer voorwaardelijke DNS de echte behoefte is

Als de werkelijke eis een privénaamruimte is die alleen oplost zolang de tunnel actief is, is hosts het verkeerde mechanisme. Windows NRPT kan een resolver voor een naamruimte kiezen, en ze maakt het adresrecord zelf niet aan; een resolver moet nog steeds antwoorden. Dat is een ander ontwerp met een andere eigenaar, en het schrapt het per overgang bewerken van het bestand volledig.

Als hosts bewust voor één vaste dienst wordt behouden, zorg er dan voor dat het adres bereikbaar blijft via de bedoelde route en dat de hostnaam stabiel blijft zodat identiteitscontroles van de toepassing blijven werken. Het leegmaken van een DNS-cache kan een verouderde regel niet herstellen die de volgende opzoeking opnieuw leest.

Test herhaalde verbindingen, twee gelijktijdige profielen en een verbreking na een niet-verwante bewerking. Het resultaat hoort te zijn dat de toewijzing van de VPN haar eigenaar volgt zonder de rest van de machine terug te spoelen.