As tarefas de VPN que restauram o ficheiro hosts apagam edições posteriores

Uma tarefa de ligação copia o ficheiro hosts do Windows, acrescenta um endereço privado, e uma tarefa de desligação copia a versão guardada de volta. Funciona durante semanas e depois, numa tarde, a máquina não chega a um sítio interno que não tem nada a ver com a VPN. A restauração fez exatamente o que lhe foi dito: repôs um ficheiro anterior à edição de outra pessoa. A falha está no modelo, não no comando de cópia.

Qualquer fluxo de trabalho que capture um ficheiro partilhado e depois o restaure herda cada alteração feita entretanto como uma perda.

Uma cópia restaurada mais tarde não é uma cópia de agora

Percorra uma sequência comum. A tarefa guarda o ficheiro e acrescenta uma entrada para o túnel. Mais tarde um administrador acrescenta uma correção não relacionada, e um segundo perfil acrescenta a sua própria entrada. Ao desligar, a restauração repõe a captura original, removendo tanto a entrada do segundo perfil como a correção do administrador. Nenhuma das duas pertencia à VPN, e ambas desapareceram.

Um único nome de ficheiro de cópia fixo agrava a situação. Um evento de ligação posterior pode copiar o ficheiro já modificado sobre o suposto original, pelo que a base de recuperação deriva para o aspeto que o ficheiro tinha no último evento.

Cada evento é uma notificação, não uma transação

Uma tarefa acionada por um evento é uma notificação. Uma religação, um encerramento interrompido ou um segundo perfil podem reformar o estado necessário enquanto uma tarefa anterior ainda está a escrever. Nada serializa as duas, e nada reverte uma alteração a meio. Além disso, um identificador de evento sozinho não diz a que perfil pertence sem o fornecedor e os seus dados. Tratar a tarefa como uma transação é a suposição que falha.

Os eventos de ligação repetidos são a outra metade: uma adição sem verificação cria uma segunda entrada idêntica, e alguns resolvedores veem então duas respostas para um nome.

Dê a cada mapeamento um proprietário

Cada linha do ficheiro hosts associa um nome de anfitrião a um endereço e não diz nada sobre qual túnel está ativo. Se a automatização for inevitável, atribua um único proprietário para os mapeamentos geridos pela VPN. Esse proprietário deve atualizar apenas as suas próprias entradas, preservar o conteúdo atual não relacionado, evitar duplicados num evento repetido e reconciliar-se com as ligações que estão realmente ativas e não com uma lista memorizada.

Quando dois túneis ativos precisam do mesmo mapeamento, uma única desligação não o pode remover enquanto o outro proprietário ainda precisa dele. Isso exige contagem de referências ou um registo explícito de propriedade, não um booleano.

Uma cópia ainda tem valor para uma recuperação revista. Não deve ser a ação normal de desligação, nem deve ser o único registo do que o ficheiro continha.

Quando o DNS condicional é a necessidade real

Se o requisito real for um espaço de nomes privado que só resolve enquanto o túnel está ativo, hosts é o mecanismo errado. O Windows NRPT pode escolher um resolvedor para um espaço de nomes, e não cria ele próprio o registo de endereço; um resolvedor continua a ter de responder. É um desenho diferente com um proprietário diferente, e elimina por completo a edição do ficheiro a cada transição.

Se hosts for mantido de propósito para um único serviço fixo, garanta que o seu endereço continua alcançável pela rota prevista e que o seu nome de anfitrião se mantém estável para que as verificações de identidade da aplicação continuem a funcionar. Limpar uma cache de DNS não repara uma entrada obsoleta que a pesquisa seguinte voltará a ler.

Teste ligações repetidas, dois perfis simultâneos e uma desligação após uma edição não relacionada. O resultado deve ser que o mapeamento da VPN siga o seu proprietário sem rebobinar o resto da máquina.