Azure VPN Client 3.4 が毎時切断される：サインイン頻度

ある利用者が接続して作業し、その後 一時間ごとに Microsoft Entra との認証が期限切れになったというメッセージで切断される。再接続は機能し、サイクルはストップウォッチのように繰り返される。何も配備していない point-to-site ゲートウェイでは、そのパターンはトンネルではなく資格情報を指す。Azure VPN Client 3.4.0 は、確立済みのセッション中に条件付きアクセスのサインイン頻度を適用し始めた。以前のクライアントはサインイン時にしか評価していなかったポリシーである。

以下の 六つの確認を順に行う。それぞれがスケジュールを裏付けるか排除する。早く止めることは、ゲートウェイを無駄に作り直す道である。

ステップ 1：正確なメッセージを読む

文言は層を分ける。Entra 認証の期限切れに関するメッセージはトークンについてのものだ。トンネルやセキュリティ アソシエーションのエラーではない。経過時間も記録する。接続から切断までを測り、勤務開始からではない。

利用者がすぐ再接続でき、ゲートウェイが依然として健全なトンネルを示すなら、見ているのはトークンの期限切れであり、死んだピアではない。

ステップ 2：クライアントのバージョンを確認する

バージョンはアプリで読み、配備の記録では読まない。変更は 3.4.0 で入ったので、3.3.1 以前はポリシーに関係なく確立済みのトンネルを生かし続ける。古いビルドの管理外ノート PC が完璧に動く一方で、チームの他の全員が毎時落ちる。これが人をゲートウェイへ戻す分断である。バージョンはクライアントの属性であり、ゲートウェイはどのビルドが接続しているか知らない。

まず試験端末を 一台更新し、時計を見る。更新後にポリシーの間隔で落ち始める端末は、本番ポリシーに触れずに仕組みを裏付ける。

ステップ 3：ポリシーの在り処を見つける

サインイン頻度は、Azure VPN エンタープライズ アプリを対象とするポリシー内の条件付きアクセス設定である。VPN ゲートウェイ リソースにも、point-to-site 構成にも、クライアント プロファイルにもない。ポリシー一覧で Azure VPN アプリを探し、セッション制御を読む。

一人の利用者に二つのポリシーが適用され得て、厳しい方が勝つ。だから設定したことのない値が有効なことがある。テナント全体のベースライン ポリシーとアプリ固有のポリシーの両方を確認する。レポートの範囲も重要だ。グループを除外するポリシーは、挙動の異なる集団を明白な説明もなく生む。

ステップ 4：計算する

切断はサインイン頻度の値の 一時間後に起きる。これは Microsoft がこのクライアントについて記録している挙動であり、七時間の頻度はおよそ 八時間の接続を与える。このずれのせいで、八時間の勤務日に選んだ値は午後に壊れて見え、九時間の試験は問題なく見える。何かを変える前に苦情を数値にする。接続時刻、切断時刻、差、そしてポリシー値に 一時間を足したものと比べる。

差がその和に合わなければ、スケジュールの仮説は誤りであり、ポリシーの調整をやめるべきだ。

ステップ 5：スケジュールと rekey を分ける

IPsec rekey、デッドピア検出、アイドル タイムアウトは、トラフィック量や静けさに結び付いた不規則な切断を生む。ストップウォッチではない。転送の途中で落ちた利用者と、静かな昼休みの後に落ちた利用者は別の仕組みを語っている。切断前の 一分間に何をしていたかを尋ねる。

証明書の問題はまた別の見え方をする。クライアントは動作中のセッションを失うのではなく接続できず、失敗は即時だ。決して完了しない MFA 要求は、きれいな毎時の切断とその後の成功した再接続ではなく、ハングとして現れる。

ステップ 6：驚かせずに展開する

クライアント更新がストア経由で利用者に届く前に告知する。挙動の変更はクライアントと一緒に届くからだ。頻度は要件から選ぶ。使い勝手のために勤務日を覆う値、あるいは紛失したノート PC が速やかにアクセスを失うべきなら短い値。どちらの要件が勝ったかを記録する。同じ設定が保護と苦情の両方を生むからだ。その後、古いビルドで走ったパイロットから外挿するのではなく、新しいビルドの端末で選択を確認する。

メッセージ、バージョン、ポリシー値、測定した間隔を 一つのメモに残す。その記録は次の報告に作り直しではなく 一分で答える。