実家には RaspberryPi があり、PiVPN をセットアップして、私と数人の友人に個人用 VPN サービスを提供するために構成しています。この VPN は最初から問題なく動作しており、PC で使用していますが、エラーは一度も発生していません。
最近、実家に Windows10 を搭載した別のコンピューターを設置し、さまざまな目的でサーバーとして動作させました (この問題に関係する場合、Plex Media Server を備えたホーム マルチメディア サーバーとして、また個人使用の Git リポジトリとしても使用しています)。VPN に自動的に接続する必要があるため、次の操作を実行しました。
- 私は、対応する .ovpn ファイルを生成するように PiVPN を設定し、新しいサーバー マシンに OpenVPN GUI クライアントをインストールして、ovpn ファイルをインポートしました。実際のところ、VPN へのすべての接続に常に同じ IP を使用するように、静的 IP を設定しました。
- OpenVPNをサーバーの起動時に自動的に接続するように設定しました。このフォルダにOpenVPN GUIへの直接リンクを配置することでこれを実現しました
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp。その直接リンクには次の引数がありました。"C:\Program Files\OpenVPN\bin\openvpn-gui.exe" --connect ServerW10.ovpn AC が復旧すると自動的に起動するようにサーバー BIOS を構成しました (そのため、停電してもサーバーは再起動します)。また、Win10 のインストール時に作成したユーザーに自動的にログインするように構成しました。これにより、サーバーは電源がオンになると常にログイン状態になります。
実家の電力消費が心配なので、このサーバーを3時間操作がないとスリープするように（Windows 10の設定）、午前2時になると常にスリープするように（バッチスクリプトを使用）設定しました。
自動スリープ機能のため、Wake-on-LAN パケットを受け入れてサーバーを起動するように BIOS を構成しました。これを数回テストしたところ、うまく機能しました。この方法で、3 時間 (私の目的には十分) 必要なときにいつでもサーバーを起動できました。
私は数日かけてサーバーをテストしました。手動でスリープ状態にしたり、3時間操作がない状態でスリープ状態にしたり、強制的にシャットダウンしたりしましたが、OpenVPN は常に正常に動作し、問題なく再接続されました。
問題は、「午前 2 時のスリープ」後にサーバーへの VPN 接続をテストしたときに発生しました。サーバーを起動し、通常どおり静的 VPN IP で ping を実行しようとしましたが、接続できませんでした。TeamViewer からログインして何が起こっているかを確認したところ、OpenVPN の GUI を開くと、次のようなループに陥っていることがわかりました。
Thu Mar 01 10:26:28 2018 OpenVPN 2.4.4 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Sep 26 2017
Thu Mar 01 10:26:28 2018 Windows version 6.2 (Windows 8 or greater) 64bit
Thu Mar 01 10:26:28 2018 library versions: OpenSSL 1.0.2l 25 May 2017, LZO 2.10
Thu Mar 01 10:26:29 2018 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Thu Mar 01 10:26:29 2018 TCP/UDP: Preserving recently used remote address: [AF_INET](my ip):(my port)
Thu Mar 01 10:26:29 2018 UDP link local: (not bound)
Thu Mar 01 10:26:29 2018 UDP link remote: [AF_INET](my ip):(my port)
Thu Mar 01 10:27:29 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Mar 01 10:27:29 2018 TLS Error: TLS handshake failed
Thu Mar 01 10:27:29 2018 SIGUSR1[soft,tls-error] received, process restarting
Thu Mar 01 10:27:34 2018 TCP/UDP: Preserving recently used remote address: [AF_INET](my ip):(my port)
Thu Mar 01 10:27:34 2018 UDP link local: (not bound)
Thu Mar 01 10:27:34 2018 UDP link remote: [AF_INET](my ip):(my port)
Thu Mar 01 10:28:34 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Mar 01 10:28:34 2018 TLS Error: TLS handshake failed
etc...
自分の PC で VPN をテストしたところ、いつもどおり問題なく動作したので、サーバーのせいである可能性が最も高いです。
個人的には、他のスリープ方法 (手動スリープと非アクティブ スリープ) では問題がなかったため、午前 2 時に PC をスリープ状態にするために作成してプログラムしたバッチ スクリプトと関係があるのではないかと考えています。バッチ スクリプトは次のようになります。
rundll32.exe powrprof.dll,SetSuspendState 0,1,0
このスクリプトを使用したのは、このためのバッチ スクリプトを実行する方法に関するチュートリアルを見たからです。そのチュートリアルで述べられているように、休止状態ではなくスリープを実行するために次のコマンドも実行しました。
Powercfg -H OFF
何が問題なのでしょうか?
答え1
セットアップに 2 つの問題がありましたが、最終的には修正できました。
まず、「VPN セットアップ」には 1 つの問題がありました。OpenVPN サーバー (PiVPN を搭載した RaspberryPi) がサーバー マシンと同じサブネットにありました。
.ovpn 構成ファイルは私の個人 DNS を指していたため、サーバーマシンは RaspberryPi の VPN に接続するために、DNS にアクセスし、次に両親のルーターのパブリック IP (ルーターにリンクしていた) を介して RaspberryPi にアクセスする必要がありました。これは、VPN トラフィックがすべて固定 UDP ポートを介して RaspberryPi のローカル IP にリダイレクトされるため問題となります。つまり、RaspberryPi がサーバーマシンに送信した応答は、ルーターに到着すると、リダイレクトされた UDP ポートにより RaspberryPi に届き、サーバーマシンは返事が来なかった。
私は、.ovpn ファイルを開いて、VPN に接続するための宛先 URL を含む行を次のように変更することでこれを修正しました。
remote my.personal.dns {port_number}
これに
remote {local_raspberry_pi_IP} {port_number}
また、スリープスクリプトはOpenVPNの設定で何らかのバグがありました。理由はよく分かりませんが、休止状態を無効にすることと関係があると思います。ダウンロードしましたマイクロソフト PsToolsそして、午前2時にPCをスリープ状態にする新しいスクリプトを作成しました。新しいスクリプトは次のようになりますC:\{path_where_pstools_was_extracted}\PsTools\psshutdown.exe -d -t 0 -accepteula
これらの変更により、サーバーは最終的に期待どおりに動作するようになりました。
答え2
Windows PC (サーバー) は他のすべての時間に Pi の VPN に接続できたため、ポート リダイレクト (転送?) がここでの問題の原因であるとは考えられません。また、ローカル IP を使用して (Pi の) VPN にアクセスできるという事実は、ルーターに問題がある可能性があることを示しています。その間にパブリック IP アドレスが変更され、DNS レコードが更新されなかった可能性があります。