VPN経由でUbuntu24.04(WSL2)からEC2インスタンスへSSH接続する際に「SSH2_MSG_KEXINIT sent」で止まってしまい、接続できなかった問題（いわゆる、Path MTU Discovery black holes）への対処を記録しました。
ネット上で色々と対処された方々の記事がありますが、さらに自分にとって使いやすいようにしました。
前提条件
- Ubuntu24.04.2 LTS (WSL2 on Windows11) を使っています
- VPN経由でEC2インスタンスへSSH接続
発生した事象
Ubuntu24.04(WSL2)からVPN経由（普段使っている）でEC2インスタンスへssh接続しようとした際に、
特定の接続先（Amazon Linux 2）のみ接続できない事象が発生。
例えば、EC2インスタンスとしてA（Amazon Linux 2023）とB (Amazon Linux 2)があり、Aは接続できるが、Bは接続できない状態。
しかしながら、ホストOSのWindows11からは普通にAもBもssh接続ができている状態。
▼ホストOSのWindowsからの接続はできている
▼Ubuntu(WSL2)からの接続
「-vvv」オプションを付けてデバグメッセージを出力させてみたところ、
「debug1: SSH2_MSG_KEXINIT sent」のとろこで沈黙しています。
EC2インスタンスへの接続自体はできていて、認証キーの交換の箇所で、こちらからパケットを投げて、EC2インスタンスからの応答を受け取れずに待っている状態のように見えます。
原因の特定と対処方法
▼問題点の整理
- ホストOSからは問題なく接続できている。
- Ubuntu(WSL2)からは接続先への接続自体はできている。
- 通信の途中で応答を受け取れなくなる。
▼予想される原因
Ubuntu(WSL2)～VPN間の経路上での通信設定の何か。
おそらくMTUの問題。
※いわゆる「Path MTU Discovery black holes」問題。
▼Windows側のネットワークインターフェースを確認
▼Ubuntu(WSL2)側のネットワークインターフェースを確認
▼MTUはVPN接続時に1500から1400へ自動切換えになっている
⇒ おそらくパケットのオーバーヘッドの分、キャパオーバーで受け取れていない。
▼対処方法
Ubuntu(WSL2)側のMTUの値を小さくする。
最適値は環境によって異なるので要調整。
今回のケースでは、MTUを1258にすることで解決しました。
sudo ifconfig eth0 mtu 1258
※筆者の環境では、VPN切断時に、Ubuntu(WSL2)側のMTUが自動で元の1500に戻るようになっています。
※また、WSL2再起動時には通常の1500に戻るようになっています。
再発防止策
筆者はネットワークはそれほど詳しくないので根本的な再発防止策ではないですが、サーバー側の設定を触るのは危険であり、VPNルーターの設定も権限を持っていないので、
この問題が発生する接続先に接続する時に限ってUbuntu(WSL2)側のMTUを最適値に設定するようにしておけば良いと考えます。
ただし、残念なことに、現時点では ssh-config では pre-hook のような処理はサポートしていません。意図的にサポートしていないのか、はたまた考えが及んでいないだけなのか。。
ssh-config に pre-hook をかます ESSH というツールはありますが、5年以上メンテナンスが止まっているようなので使うのは躊躇われます。
また、今回の事象は特定の接続先でだけ発生するので、個別のシェル関数かあるいはシェルスクリプトにしておけば良いと考えます。
▼シェル関数の例：ZSHは「~/.zshrc」BASHは「~/.bashrc」
ssh-EC2-B() {
sudo ifconfig eth0 mtu 1258
ssh EC2-B
}▼実行結果
参考サイト
- 0
- 0
- 0
- 0
コメント