背景
VPNを経由した通信が遅い！となったときに、MTUが原因となる可能性があるようです。 ワークロード全体でMTUが統一されておらず、複数回パケットフラグメントが発生し、NW遅延につながるらしい。
例えば以下の場合、AppサーバーとVPNサーバー両方でパケットフラグメントが起こるため、チリツモで大変になるようです。カッコ内がMTU値です。
- ClientPC(1500) ← VPNサーバー(1000) ← Appサーバー(3000)
今回はAWS Client VPNでそのような事象が発生した際に自分が気になって調べたことをQA形式でまとめます。
免責事項
机上で集めた情報を中心に記載しているため、あくまで参考情報として扱ってください。 必要に応じて、検証やAWSサポートへの問い合わせをお願いします。
QA一覧
ClientVPNのMTUは最大何バイト?
最大1500バイト。
マネージドサービスは基盤が自動スケーリングするはずなので、障害発生しなければ基本的には1500近く出ると考えていいはず
ただし次の場合には、トラフィックの MTU は最大 1500 に制限されます。 [中略] VPN 接続経由のトラフィック
引用元: https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/network_mtu.html
ClientVPNのMTUは1500バイト以上増やせる?(=ジャンボフレームに対応できるか?)
増やせない。
ELBのように暖気申請に相当するものはなく、一つ上のQAで案内したドキュメント以外にAWSからその他公開されている情報もない(はず)。
したがって、EC2がジャンボフレームをサポートしているからといって、ワークロード全体をジャンボフレーム対応できない点に注意
AWS提供のVPNクライアントアプリ(=AWS Client VPN for xxx)でMTUはどうやって調整する?
tun-mtu パラメータを設定する。
このパラメータは、OpenVPNディレクティブのパラメータと対応している。
AWS が提供するクライアントは、次の OpenVPN ディレクティブをサポートしています。 [中略] tun-mtu
引用元: https://docs.aws.amazon.com/ja_jp/vpn/latest/clientvpn-user/connect-aws-client-vpn-connect.html
したがって、パラメータの詳細は、OpenVPNClientの公式ドキュメントの TUN MTU を参考にすること
TUN MTU Setting: The maximum transmission unit (MTU) used over the VPN tunnel. Leave this at 1500, unless otherwise directed by a support staff or a network professional.
引用元: https://openvpn.net/vpn-server-resources/using-dd-wrt-with-openvpn-access-server/
ClientVPNを含めたワークロードにおける最適なMTU値をどうやって決める?
エンドツーエンド(例えば、クライアント→対向サーバー)で、パケットフラグメントを禁止した前提のpingコマンドを流す。徐々にデータ部サイズを1500から下げて、フラグメントせずpingが通る最適なMTUを探す。
以下はWindowsで実行する場合。(Linux系はオプションが違うので注意)
ping -n 1 -l 1500 -f <対向サーバのIPアドレス>
■ 送ろうとするパケットのMTUが大きすぎる場合の実行結果Sample
> ping -n 1 -l 1500 -f xxx.xxx.xxx.xxx
xxx.xxx.xxx.xxx に ping を送信しています 1500 バイトのデータ:
パケットの断片化が必要ですが、DF が設定されています。
xxx.xxx.xxx.xxx の ping 統計:
パケット数: 送信 = 1、受信 = 0、損失 = 1 (100% の損失)、
※ DFは Don't Fragmentの略。-fでパケットフラグメントを禁止しているため出力される
菅谷 歩 (記事一覧)
