OpenVPNの問題-TLSキーネゴシエーションは60秒以内に発生しませんでした

Windows 2012サーバーでOpenVPN（バージョン2.3.10）サーバーを構成していますが、動作させることができません。

サーバーはルーターの背後にあり、1194ポートを開いて、このポートのトラフィックをサーバーに転送するルールを作成しました。

クライアントから接続しようとすると、サーバーに表示されるログは次のとおりです。

Mon Mar 21 11:11:47 2016 XX.XX.XX.XX:57804 TLS: Initial packet from [AF_INET]XX.XX.XX.XX:57804, sid=fdf7a7ac 0264c7f3
Mon Mar 21 11:12:38 2016 XX.XX.XX.XX:55938 TLS: Initial packet from [AF_INET]XX.XX.XX.XX:55938, sid=1f242a3f e454a525
Mon Mar 21 11:12:48 2016 XX.XX.XX.XX:57804 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Mar 21 11:12:48 2016 XX.XX.XX.XX:57804 TLS Error: TLS handshake failed
Mon Mar 21 11:12:48 2016 XX.XX.XX.XX:57804 SIGUSR1[soft,tls-error] received, client-instance restarting

ここで、XX.XX.XX.XXはクライアントのIPです。このことから、クライアントは少なくともサーバーに到着できるので、ルーティングやファイアウォールの問題がないことを理解しています。

ここで提供されている説明に従いましたWindows Easy Guide

興味深いのは、ストリームの途中でポート番号がどのように変化するかです。

Mon Mar 21 11:11:47 2016 XX.XX.XX.XX：57804 TLS：[AF_INET] XX.XX.XX.XX：57804、sid = fdf7a7ac 0264c7f3からの初期パケット

Mon Mar 21 11:12:38 2016 XX.XX.XX.XX：55938 TLS：[AF_INET] XX.XX.XX.XX：55938、sid = 1f242a3f e454a525からの初期パケット

これにより、クライアントとサーバーの間のどこかに、動作不良のNATデバイス、非常に短命の状態テーブルエントリを持つデバイスがあり、クライアントの確立されたストリームに適用されるソースポート番号が変更され、サーバーが1つの連続した通信ではなく、2つの短命の通信が進行中であると考えてください。

通常、このようなデバイスはUDPでのみこれを行うため、UDPを使用していることを確認し、代わりにTCPを試すことをお勧めします。これはあなたがやったことであり、問​​題を解決していることがわかりました。次のステップでは、不正な動作をしているNATデバイスを特定し、クラブハンマーで叩き、すべてのUDP通信が一時的なものであると仮定するという重大な間違いを犯さないデバイスに置き換えます。しかし、回避策としてTCPに変更することに満足していることを示しているので、問題は終わりです。

これは、Openvpnのセットアップで最も一般的なエラーの1つであり、これに関するFAQエントリがあります。これをここで引用します。

TLSエラー：TLSキーネゴシエーションは60秒以内に失敗しました（ネットワーク接続を確認してください）

OpenVPNのセットアップで最も一般的な問題の1つは、接続の両側にある2つのOpenVPNデーモンが相互にTCPまたはUDP接続を確立できないことです。

これはほとんど次の結果です。

• サーバーのネットワーク上の境界ファイアウォールは、着信OpenVPNパケットをフィルタリングします（デフォルトでは、OpenVPNはUDPまたはTCPポート番号1194を使用します）。
• OpenVPNサーバーマシン自体で実行されているソフトウェアファイアウォールは、ポート1194で着信接続をフィルタリングしています。他の設定がない限り、多くのOSはデフォルトで着信接続をブロックします。
• サーバーのネットワーク上のNATゲートウェイには、OpenVPNサーバーマシンの内部アドレスへのTCP / UDP 1194のポート転送ルールがありません。
• OpenVPNクライアント設定の設定ファイルに正しいサーバーアドレスがありません。クライアント構成ファイルのリモートディレクティブは、サーバー自体またはサーバーネットワークのゲートウェイのパブリックIPアドレスのいずれかを指している必要があります。
• 別の考えられる原因は、Windowsファイアウォールがopenvpn.exeバイナリへのアクセスをブロックしていることです。OpenVPNを機能させるには、ホワイトリストに登録する必要があります（「例外」リストに追加する）。

これらのいずれかがあなたのケースでも同じ問題を引き起こしている可能性が高いです。したがって、リストを1つずつ調べて解決してください。

参照：TLSエラー：TLSキーネゴシエーションは60秒以内に発生しませんでした（ネットワーク接続を確認してください）

このようなTLSキーネゴシエーションタイムアウトが発生していました。しかし、私の場合、リモートリンクはローカルIPアドレスであることに気付きました。

pfSenseファイアウォールのVPNは、WANインターフェイスではなくLANインターフェイスに誤って配置されていたため、エクスポートされた構成は、ファイアウォールのLAN IPアドレスに接続しようとするように設定されました。別のLAN。

これの主なポイントは次のとおりです。

• キーネゴシエーションタイムアウトを取得しても、何にでも接続できたとは限りません。

  したがって、この段階では、実際に正しい場所に接続していることを確認する価値があり、接続をブロックするファイアウォールルールなどはありません。特に、構成が自動的に生成されている場合はそうです。

  OpenVPNは接続を試みる前に資格情報を要求するため、ログインプロンプトが表示されても、接続していることを意味するわけではないことに注意してください。

• VPNサーバーが正しいインターフェイスでリッスンしていることを確認してください。

  （もちろん、これはファイアウォールルール、間違ったポート番号の挿入、TCPとUDPの混在など、発生する可能性のあるサーバー側の誤設定の1つです。）

IP、ポート、ファイアウォール、すべてなど、すべて同じようにエラーが発生し、アドバイスもありませんでした。2時間狂った。

解決策は、クライアント構成でプロトコルをUDPからTCPに変更することでした（明らかに、かなり前に意図的にUDPを無効にしました）。

これが誰かを助けることを願っています:)

LE：これで私の問題は解決しましたが、以下のコメントのように最善のアプローチではありません。TCPの代わりにUDPを使用する必要があります。クライアント設定とサーバー設定の設定が異なっていたので助かりました。

前述のソリューションはどれも機能しませんでした。私の場合、クライアントログに同じエラーが表示されていてもTLS Error: TLS key negotiation failed to occur within 60 seconds、サーバーログにはが表示されていましたVERIFY ERROR: depth=0, error=CRL has expired。

サーバーで、次の手順で接続の問題を解決しました。

# cd <easyrsa folder>
# ./easyrsa gen-crl
above command generates new crl.pem file (in my case in pki folder)
using chown/chmod make sure 'pki/crl.pem' is readable by openvpn server (for example: chmod 640 pki/crl.pem)
# systemctl restart openvpn

OpenVPNサーバーに正常に接続しなくても、または何にも正常に接続しなくても、TLSキーネゴシエーションエラーが発生する可能性があることに注意してください！

何もリッスンしていないポートで、localhostに接続するようにVPN設定を変更しました。

OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL（OpenSSL）] [LZO] [LZ4] [PKCS11] [AEAD] 2018年4月26日にビルド
Windowsバージョン6.2（Windows 8以降）64ビット
ライブラリバージョン：OpenSSL 1.1.0h 2018年3月27日、LZO 2.10
TCP / UDP：最近使用したリモートアドレスの保持：[AF_INET] 127.0.0.1:12345
UDPリンクローカル（バインド）：[AF_INET] [undef]：0
UDPリンクリモート：[AF_INET] 127.0.0.1:12345 
TLSエラー：TLSキーネゴシエーションは60秒以内に発生しませんでした（ネットワーク接続を確認してください）
TLSエラー：TLSハンドシェイクに失敗しました
SIGUSR1 [soft、tls-error]を受信し、プロセスを再起動しています
...

このエラーにより、VPNサーバーと通信しているという誤った感覚に陥ることがあります。

最初に資格情報の入力を求められることもありますが、コンピューターの外部では実際に資格情報を要求していません。

OpenVPNがパブリックIPを備えたサーバーにインストールされているが、プライベートサブネット、つまりインターネットゲートウェイへのルートを持たないサブネットにあるインスタンスにインストールされたAWSでこのエラーに遭遇しました。

OpenVPNをパブリックサブネット内のサーバーにデプロイすると、すべてうまく動作しました:)

AWSのパブリック/プライベートサブネット：https : //docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html

私もTLS key negotiation failed to occur within 60 seconds問題に出くわしました。

公式の提案から、Diamantの投稿として、ネットワーク接続に何か問題があるはずです。ただし、ファイアウォールもNATも問題を引き起こしません。

私の場合、最初に接続を確認しましたnc -uvz xxx.xxx.xxx.xxx 1194。リンクはOKです。

また、同じLAN内の他のいくつかのVPNクライアントは正常に動作します。

どこかから、udp接続に応答またはポート転送に問題があることに気付きました。

したがって、最大のIPからハングしているクライアントへの実行中のvpnクライアントを停止します。たとえば、「10.8.0.100」から「10.8.0.50」へ。

次に、停止したvpnクライアントを逆に起動します。

バン！すべてのvpnクライアントは適切に動作します。

結論として、TLS key negotiation failed to occur within 60 secondsLAN内の複数のVPNクライアントが間違ったシーケンスで開始するという問題につながる可能性があります。