Le attività VPN che ripristinano il file hosts cancellano le modifiche successive

Un’attività di connessione copia il file hosts di Windows, aggiunge un indirizzo privato, e un’attività di disconnessione ricopia la versione salvata. Funziona per settimane e poi un pomeriggio la macchina non raggiunge un sito interno che non ha nulla a che fare con la VPN. Il ripristino ha fatto esattamente ciò che gli era stato detto: ha rimesso un file precedente alla modifica di qualcun altro. Il guasto è nel modello, non nel comando di copia.

Qualsiasi flusso di lavoro che cattura un file condiviso e poi lo ripristina eredita ogni cambiamento avvenuto nel frattempo come una perdita.

Un backup ripristinato più tardi non è un backup dell’adesso

Percorri una sequenza ordinaria. L’attività salva il file e aggiunge una voce per il tunnel. Più tardi un amministratore aggiunge una correzione non correlata, e un secondo profilo aggiunge la propria voce. Alla disconnessione il ripristino rimette l’istantanea originale, rimuovendo sia la voce del secondo profilo sia la correzione dell’amministratore. Nessuna delle due apparteneva alla VPN, e ora sono entrambe sparite.

Un unico nome di file di backup fisso peggiora le cose. Un evento di connessione successivo può copiare il file già modificato sopra il presunto originale, così la base di ripristino scivola verso l’aspetto che il file aveva all’ultimo evento.

Ogni evento è una notifica, non una transazione

Un’attività attivata da un evento è una notifica. Una riconnessione, uno spegnimento interrotto o un secondo profilo possono rimodellare lo stato richiesto mentre un’attività precedente sta ancora scrivendo. Niente serializza le due, e niente annulla una modifica a metà. Inoltre un identificatore di evento da solo non dice a quale profilo appartiene senza il fornitore e i suoi dati. Trattare l’attività come una transazione è l’ipotesi che fallisce.

Gli eventi di connessione ripetuti sono l’altra metà: un’aggiunta senza controllo crea una seconda voce identica, e alcuni resolver vedono allora due risposte per un solo nome.

Assegna a ogni mappatura un proprietario

Ogni riga del file hosts associa un nome host a un indirizzo e non dice nulla su quale tunnel sia attivo. Se l’automazione è inevitabile, assegna un solo proprietario per le mappature gestite dalla VPN. Quel proprietario dovrebbe aggiornare solo le proprie voci, preservare il contenuto attuale non correlato, evitare duplicati in un evento ripetuto e riconciliarsi con le connessioni realmente attive e non con un elenco ricordato.

Quando due tunnel attivi hanno bisogno della stessa mappatura, una sola disconnessione non deve rimuoverla mentre l’altro proprietario ne ha ancora bisogno. Ciò richiede un conteggio dei riferimenti o un record esplicito di proprietà, non un booleano.

Un backup ha ancora valore per un ripristino rivisto. Non dovrebbe essere l’azione normale di disconnessione, e non dovrebbe essere l’unica registrazione di ciò che il file conteneva.

Quando il DNS condizionale è il vero bisogno

Se il requisito reale è uno spazio dei nomi privato che si risolve solo mentre il tunnel è attivo, hosts è il meccanismo sbagliato. Windows NRPT può scegliere un resolver per uno spazio dei nomi, e non crea essa stessa il record dell’indirizzo; un resolver deve comunque rispondere. È un progetto diverso con un proprietario diverso, e rimuove del tutto la modifica del file a ogni transizione.

Se hosts viene mantenuto di proposito per un unico servizio fisso, assicurati che il suo indirizzo resti raggiungibile lungo il percorso previsto e che il suo nome host resti stabile, così i controlli di identità dell’applicazione continuano a funzionare. Svuotare una cache DNS non può riparare una voce obsoleta che la ricerca successiva rileggerà.

Prova connessioni ripetute, due profili simultanei e una disconnessione dopo una modifica non correlata. Il risultato dovrebbe essere che la mappatura della VPN segua il suo proprietario senza riavvolgere il resto della macchina.