IIS Manager のリモート管理: まず WMSVC 自身のアドレスを確認する

サイトはトンネル経由で 443 に応答しているのに IIS Manager はサーバーに接続できないが、この二つの結果は矛盾ではない。Web サイトとリモート管理エンドポイントは、それぞれ別の構成と別のアクセス規則を持つ二つのリスナーだからだ。管理側は Web Management Service(WMSVC)に属し、独自のアドレス、ポート、証明書、IPv4 制限を持っている。ルートを一つ触る前に、まずそのエンドポイントを確認しよう。

二つのリスナー、二つの異なる問題

サイトへの要求は、そのサイトの HTTP.sys バインドに届き、このバインドは applicationHost 構成でサイトごと、プロトコルごとに定義される。IIS Manager からの要求は WMSVC に届き、WMSVC は既定で TCP 8172 の HTTPS に応答して、サーバーレベルで構成される。サイトのバインドは WMSVC の待ち受け先を変えず、WMSVC はサイトが応答するアドレスを変えない。両者が共有するのはマシンと証明書ストアだけで、類似点はそこで終わる。

つまり、ポート 443 に対する Test-NetConnection が成功しても、サイトのリスナーに到達できるというだけで、管理については何も分からない。

WMSVC が実際にバインドされているアドレスを突き止める

何年も前に構成された値ではなく、いま何を待ち受けているかをサーバーに尋ねる。Get-NetTCPConnection -LocalPort 8172 -State Listen はローカルアドレスを表示し、値が 0.0.0.0 や :: なら全アドレス、特定のアドレスならその一つだけを意味する。サーバーのアドレス設定が変わったのに、リスナーが廃止されたアドレスに固定されたままだと、まさにこの確認が捕まえる障害になる。

構成値はサーバーノードの IIS Manager の Management Service ページにあり、その背後では inetsrv 構成ディレクトリの administration.config にある。ファイルが示す値と、ソケットが実際にバインドされている先を比べる。

次に、影響を受けている VPN クライアントから Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed を実行して解決されたアドレスと選択された送信元アドレスを読み、VPN 上で DNS の応答が違うのはよくあることなので早い段階で除外しておく。チケットにはその正確なホスト名とポートを残す。後で別の名前と比べても、行った変更の証明にはならない。

サーバーが見る送信元アドレスを読む

WMSVC の IPv4 制限は、サーバーに届いたアドレスに対して評価されるが、それはノート PC が自分にあると思っているアドレスとは限らない。経路のどこかで VPN プールが変換されていると、サーバーは変換後のアドレスを見るので、クライアントの内部アドレスで作った許可リストは拒否する。この拒否はクライアント側からは接続失敗に見えるため、ルーティングの問題と誤診されやすい。

TCP テストの詳細出力とサーバー自身の接続テーブルを使い、制限リストを編集する前に、どの送信元アドレスが実際に届いたのかを確認する。

バインドの変更はサービス変更として扱う

WMSVC は構成を編集する前に停止する必要があるため、コンソールアクセスや IIS Manager に依存しないリモートセッションなど、別の管理経路を用意した変更として計画する。サービスを停止し、アドレス、ポート、証明書の変更を適用してから起動してリスナーが移動したことを確認するが、その間、リモートの IIS 管理を使っている他の人はセッションを失う。作業時間の前に他の管理者へ伝えておく。途中で気づくのが、二人が同じリスナーを編集してしまう典型だ。

全アドレスを選ぶのは正当な選択肢だが、近道ではなくアクセス判断として扱う。制限リストが開いたままリスナーを広げると、管理エンドポイントが誰も意図しないネットワークに露出してしまう。サーバーに複数の NIC があるなら、リスナーを管理インターフェースに限定し、データ経路はそのままにして、サイトが自らのアドレスで応答し続けることを確認する。

WMSVC が提示する証明書は、サイトの証明書とは別に選択される。アドレスを変えたら、証明書がクライアントの使うホスト名とまだ一致するか確認し、そうでなければ接続は後の TLS 段階でルーティングとは無関係の警告を出して失敗する。

到達性と信頼・アクセス許可を分けて考える

TCP が通った後、残る障害は、管理証明書の TLS 信頼、次に Windows 認証、次にそのアカウントに与えられた IIS Manager のアクセス許可という順に並ぶ。それぞれ異なるエラーを出し、どれもルートやファイアウォール規則では直らない。サービスを再起動するのではなく、エラーの文面をそのまま読む。

エンドポイント、リスナー、送信元アドレス、信頼の順に四つの確認を進めれば、ネットワークの問題を見つける前に古いバインドに行き着くことがほとんどだ。