建物のどこかに、誰も置き換えられないアプリケーションを、何にも接続すべきでないオペレーティングシステム上で動かすマシンがある。 そのホストのネットワークアダプターから外へたどるのが、トンネルがどこに属するかを見る最短の方法だ。 ほとんどの設計では、トンネルはホスト上に属さない。 保守されたゲートウェイへ一段外へ移せば、古い問題はそれが始まったアプリケーションまで縮む。

VPNクライアントではなく、ホストのアダプターから始める

アダプターのプロパティを開き、ホストに小さな専用セグメント上の固定アドレスを与え、ゲートウェイを既定ルートにする。 そうすればホストにはトンネルクライアントもトンネル資格情報も、より広い企業ネットワークへ届くルートテーブル項目も要らない。 アプリケーションが一つの遠隔サブネットを必要とするなら、まさにその一本のルートだけを追加する。

C:\> route add 10.20.30.0 mask 255.255.255.0 192.168.50.1 -p

そのコマンドは一つの宛先をゲートウェイに固定し、ほかはすべてルーティング不能のままにする。それが望む形だ。 終了コードを信じるのではなく、route print で結果を確認する。 次に、アプリケーションが今もサーバー名を解決できるか確認する。壊れたリゾルバーを持つ古いホストはネットワーク障害とまったく同じに見え、リゾルバーの修理は五分の仕事だが、誤ったネットワーク変更の後にアプリケーションを再構築するのはそうではない。

ホストが到達できない宛先は、古いネットワークスタックを攻撃へ誘導できる対象が一つ減るということだ。

更新できるハードウェアにトンネルを置く ゲートウェイには二つのインターフェースが要る。一つはホストセグメントへ、もう一つはアプリケーションのある場所へ向かい、トンネルは二つ目で終端する。 その機器はファームウェア更新を受け取り、暗号設定を交換し、古いマシンに誰も触れずにフローを記録できる。 そのベンダーはトンネル実装の修正も提供するが、ホストは決して受け取らない。

マシンが二台あることと期限は、フォーラム投稿の静的秘密のレシピをコピーする理由にならない。 一つのクライアント設定を艦隊全体に複製するのではなく、各ゲートウェイに固有のピアIDを与える。 ユニットを交換するときは、新しいものをオンラインにするまさにその瞬間に古いIDを取り消す。さもなければ同じ端点に認証する管理外のコピーが二つ残る。

鍵はゲートウェイの管理プレーンが期待する場所に保存し、設定バックアップを秘密として扱い、その設定を誰が配布できるかを確認する。今やそれが古いホストの到達範囲を決める。

ネットワークではなくサービスを許可する ポリシーは二つの接続間のプロトコル、ポート、方向で書く。 一つのアプリケーションアドレスへの一つの許可ポートが通常の答えで、ジャンプホスト経由の管理経路が残りを覆う。

古いホストの遠隔管理はアプリケーションと同じルールに乗せるべきではなく、拒否を試すことはルールを書くのと同じくらい重要だ。 ホストから拒否されるはずの宛先へ一つ要求を送り、拒否が欠けたルートではなくポリシーから来ることを確認する。 設計が新しいうちに許可したフローを記録し、文書が主張するものではなくアプリケーションが実際に使うものを見る。 ブリッジのチュートリアルが短く見えたから二つのサブネットを統合するのが、古いセグメントが静かに足場になる道だ。

ゲートウェイを迂回する近道として、古いリスナーをインターネットへ直接さらさない。 管理経路をアプリケーション経路から分け、一方の侵害が他方を渡さないようにする。 決して行使されないルールは誰も検証していないルールであり、だから拒否した宛先は受け入れ試験に入る。

復旧はトンネルなしで機能しなければならない

最初の障害の前に、誰がゲートウェイを更新し復旧するかを決め、その人がゲートウェイが終端するトンネルなしで到達できることを確かめる。 コンソールアクセス、ローカル管理ポート、帯域外経路はすべて答えとして数える。 自分が提供するトンネルを通してしか設定できないゲートウェイは、悪いファームウェア配信を辛抱強く待つ罠だ。

実際に遭遇する障害のランブックを書く。トンネル停止、ゲートウェイ死亡、ホストディスク消失だ。 ホストの復旧イメージは、まだ存在するサポート契約の下に置き、復元がそのイメージ内のソフトウェア状態と資格情報も戻すことを忘れない。

まず隔離セグメントへ復元し、アプリケーションが起動することを確認し、それから初めて何かを再接続する。ゲートウェイが変わったら、同じ場でランブックと台帳を更新する。

証明書、時計、署名の警告 インストーラーの証明書の期限切れは、今日の署名検査が何を言うかをそれ自体で予測しない。 MicrosoftのAuthenticodeタイムスタンプの指針は、署名証明書の期限が切れた後もタイムスタンプが署名を検証可能に保てること、そして検証が署名、信頼チェーン、作業を行う検証者に依然依存することを説明している。 したがって、信頼ストアの異なる二台のマシンは同じファイルについて意見が食い違うことがある。 期限切れの署名者はバイナリが悪意ある証拠ではなく、有効な署名はソフトウェアが保守されている証拠でもない。

古いインストーラーを動かすためにシステム時計を戻したり署名検査を切ったりしない。 アプリケーションをまだ支援している相手から承認済みの成果物を入手し、プラットフォームが何を受け入れるかは彼らに言わせる。 特定のビルドがXP向けの最後だったという投稿は、インストール先ではなく歴史として扱う。実際の要件はアプリケーション次第であり、保存作業が本当に必要なら本番アクセスから離れた隔離セグメントに置き、なぜ存在するかを文書化する。

関連記事