As tarefas de VPN que restauran o ficheiro hosts borran as edicións posteriores

Unha tarefa de conexión copia o ficheiro hosts de Windows, engade un enderezo privado, e unha tarefa de desconexión volve copiar a versión gardada. Funciona durante semanas e logo unha tarde a máquina non chega a un sitio interno que non ten nada que ver coa VPN. A restauración fixo exactamente o que lle mandaron: devolveu un ficheiro anterior á edición doutra persoa. O fallo está no modelo, non na orde de copia.

Calquera fluxo de traballo que capture un ficheiro compartido e despois o restaure herda cada cambio feito mentres tanto como unha perda.

Unha copia restaurada máis tarde non é unha copia do agora

Percorra unha secuencia corrente. A tarefa garda o ficheiro e engade unha entrada para o túnel. Máis tarde un administrador engade unha corrección non relacionada, e un segundo perfil engade a súa propia entrada. Ao desconectar, a restauración devolve a instantánea orixinal e elimina tanto a entrada do segundo perfil coma a corrección do administrador. Ningunha das dúas pertencía á VPN, e ambas desapareceron.

Un único nome de ficheiro de copia fixo empeórao. Un evento de conexión posterior pode copiar o ficheiro xa modificado sobre o suposto orixinal, de xeito que a base de recuperación deriva cara ao aspecto que tiña o ficheiro no último evento.

Cada evento é unha notificación, non unha transacción

Unha tarefa activada por un evento é unha notificación. Unha reconexión, un apagado interrompido ou un segundo perfil poden reformar o estado requirido mentres unha tarefa anterior aínda está a escribir. Nada serializa as dúas, e nada desfai un cambio a medio rematar. Ademais, un identificador de evento por si só non di a que perfil pertence sen o provedor e os seus datos. Tratar a tarefa como unha transacción é a suposición que falla.

Os eventos de conexión repetidos son a outra metade: engadir sen comprobar crea unha segunda entrada idéntica, e algúns resolutores ven entón dúas respostas para un nome.

Dea a cada asignación un propietario

Cada liña do ficheiro hosts asigna un nome de host a un enderezo e non di nada sobre que túnel está activo. Se a automatización é inevitable, asigne un só propietario para as asignacións xestionadas pola VPN. Ese propietario debería actualizar só as súas propias entradas, preservar o contido actual non relacionado, evitar duplicados nun evento repetido e reconciliarse coas conexións que están realmente activas e non cunha lista recordada.

Cando dous túneles activos necesitan a mesma asignación, unha soa desconexión non debe eliminala mentres o outro propietario aínda a necesita. Iso require contaxe de referencias ou un rexistro explícito de propiedade, non un booleano.

Unha copia aínda ten valor para unha recuperación revisada. Non debería ser a acción normal ao desconectar, nin debería ser o único rexistro do que contiña o ficheiro.

Cando o DNS condicional é a necesidade real

Se o requisito real é un espazo de nomes privado que só resolve mentres o túnel está activo, hosts é o mecanismo equivocado. Windows NRPT pode escoller un resolutor para un espazo de nomes, e non crea o rexistro de enderezo por si mesma; un resolutor ten que responder de todos os xeitos. Ese é un deseño distinto cun propietario distinto, e elimina por completo a edición do ficheiro en cada transición.

Se hosts se mantén a propósito para un único servizo fixo, asegúrese de que o seu enderezo siga sendo alcanzable pola ruta prevista e de que o seu nome de host siga sendo estable para que as comprobacións de identidade da aplicación sigan funcionando. Borrar unha caché de DNS non pode reparar unha entrada obsoleta que a seguinte consulta volverá ler.

Probe conexións repetidas, dous perfís simultáneos e unha desconexión tras unha edición non relacionada. O resultado debería ser que a asignación da VPN siga o seu propietario sen rebobinar o resto da máquina.