SoftEther VPN User Forum

お世話になっております。

Windows Server 2016 1台
SoftEther VPN Server 4.21

Windows Server 2016 1台
SoftEther VPN Client 4.21

Linux 3.14 200台
SoftEther VPN Client 4.08

（Windows Server 1台が、Linux 200台 とUDP通信）

Client が Windows Update を行ったタイミングから、
Linux 200台 と通信できなくなるケースが頻発しました。
（全てが通信できなくなるわけではありません）
Windows から送信するのですが、3秒以上かかってタイムアウトしていました。

Windows Updateが終了しても2時間ほど回復しませんでした。
VPN Client を再起動したところ、回復しました。

SoftEther VPN Server 4.21 をインストールしていたWindows Server 2016においても、
同時期にCPU負荷が増大し、VPN Client を再起動したところ、負荷が下がりました。

普段は発生せず、再現もできず、原因が分からずに困っております。

Windows Update でクライアントの負荷が上がった場合、
このように通信ができなくなり、再起動まで回復しなくなるケースについて、
①何らかの原因は推定できますでしょうか？
②設定等で回避できるでしょうか？

この Windows Server の VPN Client と Linux の VPN Client は同一の仮想 HUB に接続しているでしょうか？
また、接続設定やセキュリティポリシーでデフォルトではない設定は行われているでしょうか？
また、仮想HUBから外部には仮想NATやローカルブリッジで接続があるでしょうか？

>Windows Server の VPN Client と Linux の VPN Client は同一の仮想 HUB に接続
同一の仮想 HUB に接続しております。

>接続設定やセキュリティポリシーでデフォルトではない設定
セキュリティポリシーなどは変更しておりません。
接続に関して、特に意識して変更しておりませんが、何か気づきましたら続報いたします。

>仮想HUBから外部には仮想NATやローカルブリッジで接続
ございません。

状況から推測すると、Windows Update をきっかけにして、複数 IP アドレスに対応していない何かのアプリケーションが大量のパケットを VPN に送信して、VPN の処理能力が溢れてしまったのではないかと思われます。
今度問題が再現するようであれば、症状発生中に Wireshark などのパケット傍受ソフトを使用して、どのような通信を行われているのか確認し、併せて netstat -abo コマンドなどで通信を行っているプロセス名を記録し、ポート番号などを突き合わせて不正な挙動となっているアプリケーションを特定するという方法が良いと思われます。

回答ありがとうございます。

ご指摘のように、何らかのアプリケーションが原因という場合、
Windows Server 2016 1台 上の
VPN Client (SoftEther VPN Client 4.21) を再起動するまで通信が回復しないのは何故か推測できますでしょうか？
（Linuxは通信障害で随時再起動していますが、通信は回復しませんでした）

VPN Client が何らかのアプリケーションの送信を大量にプールするなどの現象はあり得ますでしょうか？

これは推測の上に推測を重ねることになりますが、例えばWindows Updateの際に、一時的にネットワークデバイスが消えるなどして、今まで物理ネットワーク側と通信していたアプリケーションがVPN側でソケットを作り直してしまい、それげ原因で誤動作する状態に陥ったけれど、VPN client の再起動によって仮想 LAN カードが使用できない状態になることで回復した、といった可能性は考えられると思います。

ありがとうございます。とても参考になります。

Windows Updateの再試験でも再現せず、

Windows Server 2016 1台 VPN Client (SoftEther VPN Client 4.21)
が、推奨性能ギリギリであることと、
ウイルス対策ソフトが定期的に稼働していることによって、
ご指摘のような現象が発生したのではないかと考えております。

もし、似たような事例をご存じでしたらお教えいただければと思います。

不正なパケットが大量に送信されてしまうケースでは、L2またはL3のループが生じているケースが多いです。
(なので、次回発生時にはパケットのキャプチャをお勧めしています。)

了解しました。ありがとうございました。