web-dev-qa-db-ja.com

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です。このことから、クライアントは少なくともサーバーに到達できるので、ルーティングやファイアウォールの問題はないことがわかります。

私はここに提供された説明に従いましたEasy Windows Guide何かアイデアはありますか？

openvpn
14
vmasanas

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

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

2016年3月21日月曜日11:12:38 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に変更して問題ないことを示したので、問題は終了しました。

21
MadHatter

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

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

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

これはほぼ次の結果です。

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

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

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

3
Diamond

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

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

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

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

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

    OpenVPNが接続を試みる前に資格情報を要求するため、ログインプロンプトを取得しても、接続されていることを意味するわけではありません。

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

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

3
mwfearnley

前述の解決策はどれも機能しませんでした。私の場合、クライアントログに同じエラーが表示されましたが、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
1
mpprdev

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

VPN構成を変更して、何もリッスンしていないポートでlocalhostに接続しました。

 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:12345TLSエラー：TLSキーネゴシエーションが60秒以内に発生しませんでした（ネットワーク接続を確認してください）
 TLSエラー：TLSハンドシェイクに失敗しました
 SIGUSR1 [soft、tls-error]を受信しました、プロセスを再起動しています
 ...

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

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

1
mwfearnley

私は同じエラーを抱えており、助言はありませんでした。IP、ポート、ファイアウォールなど、すべてが問題ないように見えました。 2時間狂ってしまいました。

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

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

LE：これで私の問題は解決しましたが、以下のコメントのとおり、これは最善の方法ではありません。 TCPの代わりにUDPを使用する必要があります。クライアント構成とサーバー構成の間で異なる設定があったので、それは私を助けました。

1
bosch

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

OpenVPNをパブリックサブネット内のサーバーに展開すると、すべてうまくいきました:)

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

0
Zoltán

考えられる理由の1つは、サーバーがクライアントでサポートされているTLSより新しいTLSバージョンを必要とする場合です。つまり、1.2対1.0です。

試みるべき明らかなことは、OpenVPNクライアントを更新するか、TLS 1.0を受け入れるようにサーバー側を変更することです。

0
ozk

TLS key negotiation failed to occur within 60 secondsの問題にも遭遇しました。

公式の提案から、ディアマントの投稿のように、ネットワーク接続に何か問題があるはずです。ただし、ファイアウォールもNAT=も問題の原因ではありません。

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

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

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

そのため、実行中のVPNクライアントを最大のIPからハングしているクライアントに停止します。たとえば、「10.8.0.100」から「10.8.0.50」に変更します。

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

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

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

0
samson.wang