※後に根本的解決方法を見つけました
その内容は以下のリンク先になります。
以下の記事は上記リンク先の解決方法を見つける前の、応急措置として考えたものです。基本的には上記リンク先の方法を使うべきだと思います。以下の記事は途中経緯ということで削除せず残しておこうと思います。
クライアントのConfigにreneg-sec 0を入れてとりあえず解決
実はここ2週間ほどOpenVPNによる拠点間接続で一定時間後に接続が切れる問題に悩んでいて、家に帰ってからもずっとその調査と研究に没頭していました。結論から言うとこのような症状が出ている場合、自分の環境下ではサーバ側Configに「 reneg-sec 86400 」を、クライアント側Configに「 reneg-sec 0 」を入れることで解決できました。ただこの設定にはセキュリティのリスクを伴いますので、自己責任で扱ってください。
以下症状や経緯等の記述ですので、興味のある方は読んでみてください。
構築した環境
- 拠点A（サーバ）
Windows Server 2012 R2 Standard
OpenVPN 2.4.8 I602
ローカルエリア接続とTapをブリッジ
- 拠点B（クライアント）
Windows Server 2012 R2 Standard
OpenVPN 2.4.8 I602
ローカルエリア接続とTapをブリッジ
数分～数時間後に接続が切れ、その後復帰しない
前述のような環境で構築したVPNは数分～数時間後に接続が切れて、その後復帰しないという事象が発生しました。クライアント側の仮想LANが何やらスタック？しているようで、OpenVPNのサービスを再起動してもプロセスが残ったまま正しく再起動できず、ConfigのVerbを5にしてログを見ると以下のようなエラーが出ていました。
CreateFile failed on TAP device: \\.\???\{???-???-???-???-???}.tap: Too many links (errno=31)
色々調べて解決法を試してみたけどどれも効果はありませんでした。
ログにTLS: soft resetを発見
目を皿のようにしてログを読み漁ること数日間。一定の間隔でこのTLS: soft resetが出ていることに気付きました。そしてVPNが切れたタイミングもだいたい同じ。ひょっとしてこれが原因なのでは？ということでGoogleで調べてみた所、これはreneg-secで制御できることが分かりました。そこでサーバ側Configに86400秒（24時間）毎に再ネゴシエーションを行う「 reneg-sec 86400 」を、クライアントConfigには再ネゴシエーションしない「 reneg-sec 0 」を入れた所、接続は安定してつながるようになりました。
この設定ではセキュリティ性が落ちる可能性がある
OpenVPNのデフォルトではサーバ、クライアント共に3600秒（1時間）毎に再ネゴシエーションする設定になっています。本稿の解決策ではこれをサーバ側で86400秒（24時間）、クライアント側で無しと、大幅に削減することになります。本当ならデフォルトの設定のまま安定接続できるのが一番望ましいのですが…。解決策を知っている方は教えていただけると嬉しいです。
0 件のコメント:
コメントを投稿
コメントはどうぞお気軽に♪ コメント投稿にはGoogle アカウントが必要です。Google アカウントはAndroidのスマートフォンを使う時に必ず作成していると思います。Gmailを使うことができる人はそれもGoogle アカウントですので使うことができます。