何が起きたのか
VPN接続中にWSL2（Ubuntu20.04, Ubuntu22.04）からGitlabに対してgit pullやgit pushなどssh接続をしようとしたところ繋がらなかった（通信ができなかった）。
コロナ禍以降、リモートワークや在宅勤務が増えたタイミングで私だけではなく
私の同僚や他の会社さんでも同様の問題が増えた印象です。
解決法
WSL2 の MTU を変更したら通信が問題なく行えるようになりました。
$ sudo ip link set eth0 mtu 1200これでもうまく動かない方は別の原因か MTU を1200ではない数字にする必要があるかもしれません。
※VPN の MTU に合わせる必要があると思われます。
原因について
使用した VPN とWSL2 の MTU 値が 異なっていたことが原因でした。
MTU(Maximum Transmission Unit)とは
MTU(Maximum Transmission Unit)とは、ネットワークで１回に送信できる最大データサイズのことです。
データ伝送の過程でMTUの異なる機器を経由することがあるのですが基本的にはいい感じに解決してくれます。（低いほうのMTUに合わせたり、フラグメンテーションというパケット分割をしてくれたり）
WSL2 と VPN の組み合わせだと問題が起きる
しかし、以下の記事によると、WSL2 と VPN でMTU が異なる場合にはデータ転送ができなくなる問題があるようです。
接続元（Windows; WSL2）と接続先（VPN ルータ）の MTU が異なる場合、小さい方が採用されます。接続元から VPN ルータにパケットを送る場合に、1500バイトを超えた場合はパケット分割（フラグメント化）が起こります。
フラグメント化はスループットが落ちてしまうのに加え、経路のどこかで分割を禁止するフラグ（DF ビット）が立っていると、送信元に ICMP パケットを送って最適な MTU を教えてもらうのですが、WSL2 がなぜか ICMP パケットを受信できないみたいで、通信がずっと待ち状態になってしまうのだと思います。（ブラックホール問題）。そのためハングアップしたように見えます。
この問題については、WSLのGithubにもIssueが上がっておりました。
https://github.com/microsoft/WSL/issues/6264
まとめ
普段意識せずに使えているネットワーク系の問題となると、
いつもより原因の調査に時間がかかってしまいますね。
私自身、この問題にあたるのは今回で２度目でしたがすぐに気づけず時間を無駄にしたので記事にしておこうと思いました。
他にも多くの記事が出てはいますが一人でもこの記事で解決する方がいらっしゃれば嬉しいです。