Les tasques de VPN que restauren el fitxer hosts esborren les edicions posteriors

Una tasca de connexió copia el fitxer hosts de Windows, hi afegeix una adreça privada, i una tasca de desconnexió torna a copiar la versió desada. Funciona durant setmanes i, un dia a la tarda, la màquina no pot arribar a un lloc intern que no té res a veure amb la VPN. La restauració va fer exactament el que li van manar: va tornar un fitxer anterior a l’edició d’una altra persona. La fallada és del model, no de l’ordre de còpia.

Qualsevol flux de treball que capturi un fitxer compartit i després el restauri hereta cada canvi fet entremig com una pèrdua.

Una còpia restaurada més tard no és una còpia de l’ara

Repasseu una seqüència ordinària. La tasca desa el fitxer i hi afegeix una entrada per al túnel. Més tard un administrador hi afegeix una correcció no relacionada, i un segon perfil hi afegeix la seva pròpia entrada. En desconnectar, la restauració torna la instantània original i elimina tant l’entrada del segon perfil com la correcció de l’administrador. Cap de les dues no pertanyia a la VPN, i ara totes dues han desaparegut.

Un sol nom de fitxer de còpia fix empitjora la cosa. Un esdeveniment de connexió posterior pot copiar el fitxer ja modificat sobre el suposat original, de manera que la base de recuperació es desplaça cap a l’aspecte que tenia el fitxer en el darrer esdeveniment.

Cada esdeveniment és una notificació, no una transacció

Una tasca activada per un esdeveniment és una notificació. Una reconnexió, un apagat interromput o un segon perfil poden reformar l’estat necessari mentre una tasca anterior encara escriu. Res no serialitza les dues coses i res no desfà un canvi mig acabat. A més, un identificador d’esdeveniment tot sol no diu a quin perfil pertany sense el proveïdor i les seves dades. Tractar la tasca com una transacció és la suposició que falla.

Els esdeveniments de connexió repetits són l’altra meitat: afegir sense comprovar crea una segona entrada idèntica, i alguns resolvers veuen llavors dues respostes per a un sol nom.

Donau a cada mapatge un propietari

Cada línia del fitxer hosts mapitza un nom d’amfitrió a una adreça i no diu res sobre quin túnel està aixecat. Si l’automatització és inevitable, assignau un sol propietari per als mapatges gestionats per la VPN. Aquest propietari hauria d’actualitzar només les seves pròpies entrades, preservar el contingut actual no relacionat, evitar duplicats en un esdeveniment repetit i reconciliar-se amb les connexions que estan realment actives i no amb una llista recordada.

Quan dos túnels actius necessiten el mateix mapatge, una sola desconnexió no el pot eliminar mentre l’altre propietari encara el necessita. Això requereix comptatge de referències o un registre explícit de propietat, no un booleà.

Una còpia encara té valor per a una recuperació revisada. No hauria de ser l’acció normal en desconnectar, ni hauria de ser l’únic registre del que contenia el fitxer.

Quan el DNS condicional és la necessitat real

Si el requisit real és un espai de noms privat que només es resol mentre el túnel està aixecat, hosts és el mecanisme equivocat. Windows NRPT pot triar un resolutor per a un espai de noms, i no crea pas el registre d’adreça; un resolutor encara ha de respondre. És un disseny diferent amb un propietari diferent, i elimina del tot l’edició del fitxer a cada transició.

Si es manté hosts a propòsit per a un sol servei fix, assegurau-vos que la seva adreça segueixi sent abastable per la ruta prevista i que el seu nom d’amfitrió es mantingui estable per tal que les comprovacions d’identitat de l’aplicació continuïn funcionant. Esborrar una memòria cau de DNS no pot reparar una entrada obsoleta que la consulta següent tornarà a llegir.

Proveu connexions repetides, dos perfils simultanis i una desconnexió després d’una edició no relacionada. El resultat hauria de ser que el mapatge de la VPN segueixi el seu propietari sense rebobinar la resta de la màquina.