hosts ファイルを復元する VPN タスクは後からの編集を消す

接続タスクは Windows の hosts ファイルをコピーして私有アドレスを一つ追記し、切断タスクは保存した版を書き戻します。何週間も問題なく動いていたのに、ある午後、VPN とは無関係の社内サイトに届かなくなります。復元は命じられたとおりに動いただけでした：他人の編集より前のファイルを戻したのです。誤りはモデルにあり、コピー命令にはありません。

共有ファイルのスナップショットを取り、後で復元するワークフローは、その間に加えられた変更をすべて損失として受け継ぎます。

後から復元されるバックアップは現在のバックアップではない

よくある順序をたどります。タスクはファイルを保存し、トンネル用のエントリを追記します。その後、管理者が無関係の修正を加え、二つ目のプロファイルが自前のエントリを加えます。切断時に復元は元のスナップショットを戻し、二つ目のプロファイルのエントリも管理者の修正も消してしまいます。どちらも VPN のものではなく、いま両方とも失われています。

単一の固定バックアップファイル名は事態を悪化させます。後続の接続イベントが、すでに変更されたファイルを元のファイルとみなして上書きすることがあり、復旧の基準が最後のイベント時のファイルの姿へとずれていきます。

あらゆるイベントは通知であり、トランザクションではない

イベントで起動するタスクは通知です。再接続、途中で切れたシャットダウン、二つ目のプロファイルは、先行するタスクがまだ書き込み中でも必要とされる状態を作り変えます。両者を直列化するものはなく、中途半端な変更を巻き戻すものもありません。またイベント識別子だけでは、プロバイダとそのデータがなければ、どのプロファイルのものか分かりません。タスクをトランザクションとして扱うことが、失敗する前提です。

繰り返される接続イベントがもう半分です：確認なしの追記は同一のエントリを二つ作り、名前一つに対して解決先が二つ見えることがあります。

各マッピングに所有者を与える

hosts ファイルの各行はホスト名をアドレスに対応づけるだけで、どのトンネルが上がっているかは何も語りません。自動化が避けられないなら、VPN が管理するマッピングに一つの所有者を割り当ててください。その所有者は自分のエントリだけを更新し、無関係な現在の内容を保ち、繰り返しイベントで重複を避け、記憶した一覧ではなく実際に有効な接続に突き合わせるべきです。

二つの有効なトンネルが同じマッピングを必要とするとき、片方の所有者がまだ必要としている間に、一方の切断でそれを削除してはなりません。参照カウントか明示的な所有記録が必要で、真偽値では足りません。

バックアップはレビュー済みの復旧には依然として価値があります。ただし通常の切断動作にすべきではなく、ファイルに何が入っていたかの唯一の記録にすべきでもありません。

条件付き DNS が本当の要件である場合

本当の要件が、トンネルが上がっている間だけ解決する私有名前空間なら、hosts は誤った仕組みです。Windows の NRPT は名前空間に対してリゾルバーを選べますが、アドレスレコード自体は作りません；最終的にはリゾルバーが答える必要があります。これは別の所有者を持つ別の設計であり、遷移のたびのファイル編集を完全に排除します。

hosts を単一の固定サービス用に意図的に残すなら、そのアドレスが想定経路で到達可能なままであること、ホスト名が安定していることを確かめてください：アプリケーションの同一性確認が動き続けるには、それが要ります。DNS キャッシュを消しても、次の検索が再び読む古いエントリは直りません。

繰り返しの接続、同時に二つのプロファイル、無関係な編集後の切断を試してください。結果は、マシンの残りを巻き戻すことなく VPN のマッピングが所有者に従うことであるべきです。