【ライタスの日常】Loop/Power Automateが繋がらなかった話 (後編)
こんにちは。 ライタスの営業担当・Kです。 前編では、 事務所ネットワークから Microsoft Loop や Power Automate に アクセスできなかった事象について、 相談背景と初期調査の内容をご紹介しました。 後編では、 調査を進める中で 原因として整理したポイント と、 最終的にどのような対応につながったのかを 事例としてまとめます。 【原因として考えられたこと】 前編で触れた通り、今回の事象では、 名前解決はできている URL フィルタを調整しても改善しない WiFi 環境では問題ない 一部の Windows PC のみで発生 といった状況が確認されていました。 これらの点から、 アプリケーションや URL 制御ではなく、 ネットワーク経路や通信サイズに起因する問題 の可能性があります。 調査を進める中で浮かび上がったのが、IPoE 環境における MTU の影響です。 【IPoE 環境と MTU の影響】 今回の環境では IPoE 回線が利用されており、 IPv4 通信は IPv6 パケット内にカプセル化されて 転送される構成となっていました。 この構成では、IPv6 ヘッダー等のオーバーヘッドが加わることで、 IPv4 通信において実際に利用できるパケットサイズ(実効 MTU)が 標準より小さくなる場合があります。 Microsoft の一部サービスでは、 HTTPS 接続時の TLS ハンドシェイクで比較的大きなデータが送受信されるため、 この影響を受けやすいケースがあります。 結果として、 通信途中でパケットが破棄され、 接続が完了しない挙動になっていたのではないか考えられます。 【なぜ WiFi 環境では問題なかったのか?】 今回の事象では、 事務所ネットワーク:アクセス不可 WiFi ネットワーク:問題なし という違いがありました。 これは、 ネットワーク経路や適用されているポリシーの違いにより、 MTU の影響を受ける・受けない差が発生していたためと考えられます。 同じ拠点内であっても、 経路や設定が異なることで挙動に差が出る点は、切り分けの際に注意が必要だと感じました。 対応方法(要点) 今回の事象について、 調査結果を踏まえて以下のように原因と対応方針を整理しました。 ー 事務所ネットワークにて、一部 Microsoft サービ...