【ライタスの日常】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 サービスへ接続できない事象が発生

ー　原因として、IPoE 環境における MTU 不足により、通信途中でパケットが破棄されている可能性がある。

ー　対応策の一つとして、FortiGateの WAN インターフェースにTCP MSS Clamping を設定する方法を共有

ー　MSS 値を 1420 に制限することで、IPv4 over IPv6 環境でもパケットサイズが物理 MTU を超えないよう調整

ー　その結果、パケットの断片化や破棄が発生せず、通信が正常に完了するようになり、問題は解消いたしました。

まとめ

今回のように、

一部の Microsoft サービスだけ接続できない

名前解決や URL 許可では解決しない

ネットワークによって挙動が変わる

といった事象では、

MTU や通信経路といった

低いレイヤーの要因が

関係しているケースもあります。

すぐに原因が特定できない場合でも、状況を整理しながら切り分けを進めることが大事だなと改めて感じた事例でした。

それでは、今日はこのあたりで。

――――――――――――――

このブログは、ライタス株式会社のメンバーが 日々の業務や日常の中で感じたことを、 ゆるく綴っているブログです。

仕事の話から日常のちょっとしたことまで、 ライタスの雰囲気が少しでも伝われば嬉しいです。

――――――――――――――

#ライタスの日常

#事例紹介

#MicrosoftLoop

#PowerAutomate

#ネットワーク調査