ウィンドウが開き、資格情報を求め、そのまま空白のままになるか落ちる。そして利用者は VPN がリモートアクセスを壊したと報告する。トンネルは正常で、セッションが一度も始まっていないこともある。アプリが実際にどこで動いているかを知ることがこれらの事例を分ける。トンネルとデスクトップセッションは提供するものが違い、失敗する場所も違うからだ。

トンネルは端末にネットワークへの経路を与える。一方、デスクトップセッションは別のマシンにつながった画面とキーボードを与える。

症状はアプリが動く場所で決まる

トンネル経由の直接アクセスでは、アプリは自分の端末で動き、その要求は許可されたプライベート経路を通ってファイル共有や社内サイトへ届く。そのアプリが失敗するなら、名前解決かルーティングの問題を見ているのであり、ローカルのプログラム自体はそれ以外は正常に動いている。

リモートセッションでは、アプリは遠隔のマシンで動き、端末はその映像を受け取る。これで障害の一覧はまったく変わる。セッションホストが利用可能であること、接続を受け付けるサービスが待ち受けていること、そしてアカウントがトンネルとホストの両方で許可されていることが必要だ。トンネルへのログインに成功した後の空白のウィンドウは、通常、二つ目の認証が一度も通らなかったことを意味する。

どちらの設計も同じ利用者のために併存しうる。よくある構成は、まずトンネルを通し、その内側でデスクトップセッションを使う。だからこそ部分的な成功を、壊れた一つの機能と読み違えやすい。

性能はラベルではなく作業内容に従う

大きなファイルをトンネル経由で直接開くと、そのファイルがネットワーク上を移動する。見える遅れはクリックではなく転送に従う。リモートセッションではファイルがデータセンターから出ないこともあり、転送が消えて、代わりに画面の更新と入力の遅延が残る。どちらの設計も一般に速いわけではない。動かしているものが違うからだ。指標を選ぶ前に、利用者が実際に何の量を待っているのかを尋ねる。

誰かが遅さを訴えるとき、この違いが効く。入力中にもたつくリモートセッションは往復の遅延に敏感であり、同じトンネル越しの直接のファイルオープンは帯域に敏感だ。一般的な速度の数字ではなく作業そのものを測り、利用者が訴えているまさにその操作を試す。

遅延の大きい経路での対話的な作業は、画面の変化が大きいほど悪化する。だから文書をスクロールする感覚は、静止したウィンドウを見るときと違う。訴えが完了までの時間ではなく応答性についてなら、作業の置き場所こそ変える価値のある変数だ。

失敗したときは層ごとに分けて確認する

外側から内側へ進み、各手順が何を返すかを記録する。すべてを一度に再起動すると証拠が消えるからだ。トンネルが上がっていることを確かめ、次にプライベート経路が解決することを確かめ、次にセッションホストが接続を受け付けることを確かめ、次にアカウントがそこで許可されていることを確かめる。

Test-NetConnection -ComputerName 172.20.8.30 -Port 3389
Resolve-DnsName workstation-14.corp.example
qwinsta /server:172.20.8.30

応答する経路と拒否するポートは別の結果であり、資格情報が拒否されているのにポートが応答するのは三つ目の結果だ。配備が社内へのトンネルではなく管理されたアクセスゲートウェイを使っているなら、プライベート経路が失敗したからといってデスクトップサービスをインターネットにさらすのではなく、その構成に従う。

暗号化と認可も別の仕事だ。トンネルは経路を暗号化し、セッションプロトコルはホストに対してあなたを認証し、アプリがさらに認証することもある。最初の確認を通っても三つ目については何も分からない。そしてネットワークの外から遠隔の PC に到達するための指針は、機能する配備に必要な部品を説明している。

組織の内側に残すべきものを決める

リモートセッションがすべての文書をデータセンターに置くという前提は安全ではない。クリップボードの共有、リダイレクトされたドライブ、印刷は、ポリシーが許すたびに二つの環境の間で情報を動かしうる。そしてトンネルは、許可された利用者が到達可能な共有からどのファイルを複製するかを制限しない。封じ込めが要件なら、構成図を信じるのではなく、セッションの実際の転送制御を確認する。その持ち主に代わって何かを約束する前に、どのリダイレクトが有効かを尋ねる。

セッションの寿命も意外な点だ。ウィンドウを閉じてもホスト側でセッションが動き続けることがあるので、トンネルを失うと一時的に届かなくなるだけかもしれない。共有マシンで作業を終える承認された方法を学び、サインアウトが起きたと決めつけずに、後でホストを確認する。

どの層が失敗したか、何を変えたか、利用者が何を再確認すべきかを書き残す。その記録は、誰も再現できない解決よりも価値がある。

関連記事