新しい VPN が現れ、認証も通り、そして二年間そのマシンに住んでいた第三者製の VPN が同じ再起動で消えた。展開ログには何も書かれていなかった。展開のどこもそれに触れていなかったからだ。パッケージはグローバル電話帳を置き換えており、もう一方の接続はそのファイルの一項目だった。これはコピー操作が、コピー操作として当然すべきふるまいをしただけのことだ。

直し方は、より良いコピーではない。ファイルをコピーしないことだ。

電話帳が実際に含んでいるもの

電話帳はプロファイルではなく、接続定義の入れ物だ。ユーザーごとの項目はユーザープロファイルの下にあり、全ユーザーの項目はマシン全体の ProgramData パスの下にあるので、そのファイルに書き込む展開は、ローカルの全ユーザーに一度に触れる。同じファイルには他社製の項目も入っており、副次的な被害はそこから生まれる。

接続定義だけでは話は終わらない。ルート、DNS ポリシー、信頼された CA の素材、そして ID は、それぞれ別の担当が用意する。

どのスコープがプロファイルを所有しているかを見極める

何かを書く前に、両方のスコープを一覧する。Get-VpnConnection は現在のユーザーの項目を返し、Get-VpnConnection -AllUserConnection はマシン全体の項目を返す。同じ名前が両方に、違う設定で存在しうる。どちらのスコープを展開が所有するのかを決めて書き留めること。間違ったスコープを更新すると、利用者は古いプロファイルでつなぎ続け、あなたの変更は誰も読まないファイルの中に残る。SYSTEM として実行されるスケジュールタスク も、ログオン中のユーザーとは別のプロファイル群を見ている。

所有者を名指しすることが、次のエンジニアにファイル全体のコピーを繰り返させないための一歩だ。

名前付き接続を作るか更新する。それ以外はしない

ネイティブの Windows プロファイルなら、Add-VpnConnection が一つの項目を作り、-AllUserConnection がマシン全体のスコープを選ぶ。まず -WhatIf を付けて実行し、プレビューを利用者の苦情ではなく自分の記録に残す。

Add-VpnConnection -Name 'Office VPN' -ServerAddress 'vpn.example.com' -TunnelType Ikev2 -AuthenticationMethod Eap -EapConfigXmlStream $approvedEapXml -AllUserConnection -WhatIf

EAP XML は正規の出所から来なければならない。動作する参照プロファイルから書き出したものか、実際のゲートウェイ向けに管理ツールが生成したものだ。サーバー信頼の設定が正しくなければ、プロファイルは誤った相手につながるか、どこでも失敗する。どちらも展開の成功ではない。

項目がすでにある場合は、設定を比べて Set-VpnConnection で更新する。削除して作り直してはいけない。削除は、動いている構成が誰も文書化していない項目を失う道であり、無関係な項目が大規模な片付けに巻き込まれる道だ。

次のポリシー更新で古いプロファイルを戻す二つ目の管理システムがないか確認する。試験運用がこけるのは、たいてい cmdlet ではなくここだ。

すでに別の VPN があるマシンで試験する

無関係なマシン全体の項目がある試験機を選び、展開し、三つを確認する。新しいプロファイルが意図したスコープに現れること、認証が非公開リソースに届くこと、無関係な項目が今もつながること。さらに二回展開し、二回目の実行が自分のプロファイルだけを変えることを確かめる。この三つ目の確認が、自分の項目には冪等で、それ以外には破壊的なパッケージを捕まえる。

削除も同じ原則に従う。Remove-VpnConnection -Name 'Office VPN' -AllUserConnection は一つの項目を引退させ、ファイルの残りには触れない。

以前の意図した構成を入手可能なままにしておく。範囲を限った切り戻しが、マシン状態全体の復元ではなく、一つのプロファイルの再取り込みで済むように。

関連記事