Azure Point-to-Site VPN のログはどこにある？Monitor で確認

ユーザーが Point-to-Site ゲートウェイに接続できず、ゲートウェイのブレードを開いても、ページのどこにも接続履歴がありません。構成、証明書、状態はすべて表示されますが、レコードはありません。ログ自体は存在しますが、ネットワークのページが生成しているわけではありません。ログはゲートウェイ リソースに接続された診断設定から出力され、その設定は Monitor の下にあります。そのため明白な場所での最初の検索は何も返さず、人々はサービスに監査証跡がないと結論づけます。

明白な検索が失敗する理由

古いガイダンスには Azure Point-to-Site VPN に監査がないと書かれており、サービスが接続ごとのレコードを公開していなかった当時はそれは正しかったのです。現在のゲートウェイはトンネルの診断レコードを公開するため、有用な問いは変わりました。ログの有無ではなく、どのリソースが出力し、どのカテゴリを有効にしたかです。ゲートウェイのブレードは構成用の画面であり、構成用の画面がログ ビューアーを兼ねることはほとんどありません。診断設定はリソースごとのオブジェクトなので、選んだリソースが後続のすべてを決めます。

混乱のもう半分は認証です。証明書ベースの Point-to-Site 接続は、ID プロバイダーのようにはユーザーごとのサインイン イベントを生成しないため、パスワードを入力する特定の人物のレコードは存在しません。

診断設定をゲートウェイ リソースに接続する

Monitor を開き、次に Diagnostic settings を開いて、対象を含む仮想ネットワークではなく仮想ネットワーク ゲートウェイ自体を対象とする新しい設定を追加します。P2SDiagnosticLog という名前の Point-to-Site 診断カテゴリを選びます。これがクライアントごとの接続レコードを保持します。トンネル、ルート、IKE のカテゴリは、それらが対象とするサイト間エラーにのみ追加します。次に、データを自分で管理する Log Analytics ワークスペースに送信し、保持期間は意図して選んだ値にします。検索に失敗するほとんどは、機能の欠落ではなく、誤ったリソースに接続された設定です。

カテゴリの一覧はゲートウェイの種類と世代によって異なります。Point-to-Site カテゴリがない場合、ゲートウェイがこの機能より古いか、決して出力しない SKU で動作している可能性があるため、権限の問題を探す前に、サポートされているカテゴリを確認してください。Point-to-Site カテゴリのないゲートウェイは壊れておらず、単にそのレコードのソースになれないだけで、最も近い代替はトンネルまたは IKE カテゴリです。これは Point-to-Site セッションを表しませんが、クライアント アドレスを記録します。ログが見つからない件でサポート ケースを開く前に、カテゴリ一覧を確認してください。

使用しているモードのテーブルでレコードを読む

従来の収集モードではエントリが AzureDiagnostics テーブルに入りカテゴリが列の値として表示されますがリソース固有のテーブルではゲートウェイに独自のテーブルがあり、いずれの場合もゲートウェイ リソースと失敗した試行の前後の時間枠でクエリして個々の行ではなく相関関係を読みます。

AzureDiagnostics
| where ResourceType == "VIRTUALNETWORKGATEWAYS"
| where _ResourceId has "gateway-name"
| where TimeGenerated > ago(2h)
| project TimeGenerated, Category, OperationName, ResultType, ResultDescription
| order by TimeGenerated desc

列のセットは収集モードに従うので、クエリはスクリプトではなく形として扱ってください。探すべきは、現れてから消えるクライアント アドレスと、成功ではない結果の種類です。

ゲートウェイのレコードをクライアント側の見方と突き合わせる

ゲートウェイのログが示すのはトンネルであり、ノート PC がトンネルを構築できなかった理由ではありません。同じタイムスタンプで、RAS クライアントの Windows イベント ログ、macOS の接続ログ、またはクライアント アプリが表示したエラー テキストを集めます。対応するクライアントの試行がないゲートウェイのレコードはクライアント側を示します。クライアントが成功を報告しているのにゲートウェイが何も記録しない場合は、通常、プロファイルが別のゲートウェイを向いていることを意味します。

両方の半分を同じチケットに残してください。ゲートウェイのログだけでは誤った結論を招き、クライアントのログだけではパケットが届いたかどうかを示せません。

どちらにも何も現れない場合は、プラットフォームを疑う前にクライアントの時計を確認してください。ずれたタイムスタンプは、欠落データとまったく同じに見える形で相関を失敗させます。

保持、範囲、runbook の項目

トンネルのレコードにはクライアント アドレスと接続のタイムスタンプが含まれるため、プラットフォームの既定値のままにせず、削除スケジュールを伴う個人データとして扱ってください。また、ワークスペースがサブスクリプション内のすべてのリソースのすべてのカテゴリを取り込んでいないか確認してください。ノイズの多いワークスペースは、クライアント ログを直接読むより相関を遅くします。

最後に、設定名、ワークスペース、選んだカテゴリをゲートウェイの runbook に書き留めてください。次にクライアントをデバッグする人は、まずゲートウェイのブレードを見て、何も見つからず、ログは存在しないと結論づけるでしょう。