※後に根本的解決方法を見つけました
その内容は以下のリンク先になります。
LANアダプタを2枚使って安定稼働に成功
結論から言えばこれまでLANアダプタ1枚で運用していたところ、2枚使うことで「 reneg-sec 0 」を使うことなく安定稼働に成功しました。技術的な事はさっぱり分からないんだけど、ブリッジは予想以上に負荷がかかるようですね。以下、簡単にその構成などを紹介します。
構築した環境
- 拠点A(サーバ)
Windows Server 2012 R2 Standard
OpenVPN 2.4.8 I602
ローカルエリア接続
TAP仮想アダプタ
ブリッジ無し - 拠点A(クライアント)
Windows Server 2012 R2 Standard
OpenVPN 2.4.8 I602
ローカルエリア接続1(ゲートウェイ有り)
ブリッジ(ローカルエリア接続2 + TAP仮想アダプタ、ゲートウェイ無し) - 拠点B(クライアント)
Windows Server 2012 R2 Standard
OpenVPN 2.4.8 I602
ローカルエリア接続1(ゲートウェイ有り)
ブリッジ(ローカルエリア接続2 + TAP仮想アダプタ、ゲートウェイ無し) - 拠点C(クライアント)
Windows Server 2019 Standard
OpenVPN 2.4.8 I602
ローカルエリア接続1(ゲートウェイ有り)
ブリッジ(ローカルエリア接続2 + TAP仮想アダプタ、ゲートウェイ無し)
主な変更点は以下の二つです。
- 拠点Aのサーバとクライアントを別個のサーバ機に分けた
前回は拠点Aのサーバでブリッジしてクライアントを設けていませんでしたが、これを別々に分けました。これによって前回は拠点Aのサーバ機1台だったところ、変更後はサーバ機2台で運用しています。 - クライアントではLANアダプタを2枚使う
片方のアダプタにはゲートウェイを設定し、単独で使います。もう片方にはゲートウェイを設定せず、TAP仮想アダプタとブリッジします。こうすることで負荷分散する事が狙いです。
これによってサーバ側、クライアント側共にreneg-secの設定を記述せずデフォルト運用でも安定して稼働させることに成功しました。
また前回と違って拠点Cが増えていますが、そこではWindows Server 2019を使っています。おそらく全てWindows Server 2019にしても運用が可能ではないかと推測しますが、これは未検証です。
時々ドメインネットワークとして認識されない問題の解決
LANアダプタを2枚にしたことによって、それぞれのアダプタをOSが認識したときのタイムラグなのか、時々ドメインネットワークとして認識されず、パブリックネットワークになってしまうことがありました。基本的にパブリックネットワークのファイアウォール設定はきつくなっており、一度そうなってしまうとネットワーク越しに何かする時に支障が出る場合がありました。
この問題を解決するにはブリッジしているローカルエリア接続を一度無効にして有効にします。…が、これをいちいちサーバごとにやっていたら手間がかかって仕方がないので、スタートアップスクリプトに一定時間後にアダプタを再起動するバッチを設定して解決しました。その方法については書けば長くなるので、Google検索などしてもらえればと思いますが、結論としてはブリッジしているローカルエリア接続を一度無効にして有効にすればOKです。
※関連リンク
※関連リンク
- Windows Server + OpenVPNの拠点間接続で一定時間後に接続が切れる問題の対策【応急措置編】
このリンク先の内容は問題を見つけた時の応急措置として考えたものであり、根本的解決方法ではありません。
0 件のコメント:
コメントを投稿
コメントはどうぞお気軽に♪ コメント投稿にはGoogle アカウントが必要です。Google アカウントはAndroidのスマートフォンを使う時に必ず作成していると思います。Gmailを使うことができる人はそれもGoogle アカウントですので使うことができます。