1時間ごとにOpenVPNサーバーから切断される


12

OpenVPN構成にかなり奇妙な問題があります。からWindows 7最新の公式OpenVPNクライアントでOpenVPNサーバーに接続しています(OpenVPN 2.1.4 i386-redhat-linux-gnu)。

問題はOpenVPN、1時間後にちょうどサーバーから切断され、どのディレクティブ/オプションがこれを担当するのか理解できないことです。多分それはクライアントの問題ですか?別のWindowsシステムとWindows VPNクライアントを試しました。Linux無切断して期待通りのクライアントが働いています。

この問題のトラブルシューティングを手伝っていただけませんか?私は本を読み、グーグルで試してみましたが、一部の人々が一緒にプレイすることをお勧めkeepaliveしてreneg-secディレクティブ。しかし、それは役に立たないようです。

OpenVPNサーバー設定

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
server 192.168.2.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 10.0.0.0 255.0.0.0"
client-config-dir ccd
route 192.168.51.0 255.255.255.0
keepalive 60 600
reneg-sec 5000
hand-window 15
tls-auth ta.key 0
comp-lzo
max-clients 50
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 4
crl-verify crl.pem
management localhost 11111
plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so login
push "dhcp-option DNS 192.168.2.1"
push "dhcp-option DOMAIN example.com"
push "dhcp-option SEARCH example.com"

サーバーログ(reinit_src = 1に問題はありませんか?)

Oct  9 07:23:38 vpn openvpn[19495]: user/192.168.253.20:54568 TLS Error: TLS handshake failed
Oct  9 07:23:38 vpn openvpn[19495]: user/192.168.253.20:54568 TLS: move_session: dest=TM_LAME_DUCK src=TM_ACTIVE reinit_src=1
Oct  9 07:24:53 vpn openvpn[19495]: user/192.168.253.20:54568 TLS Error: TLS handshake failed
Oct  9 07:26:08 vpn openvpn[19495]: user/192.168.253.20:54568 TLS Error: TLS key negotiation failed to occur within 15 seconds (check your network connectivity)
Oct  9 07:26:08 vpn openvpn[19495]: user/192.168.253.20:54568 TLS Error: TLS handshake failed
Oct  9 07:26:39 vpn openvpn[19495]: user/192.168.253.20:54568 [UNDEF] Inactivity timeout (--ping-restart), restarting
Oct  9 07:26:39 vpn openvpn[19495]: user/192.168.253.20:54568 SIGUSR1[soft,ping-restart] received, client-instance restarting

クライアントログ

RwrWRwRwRwRwTue Oct 09 07:26:39 2012 us=796000 TLS: soft reset sec=0 bytes=7405621/0 pkts=9459/0
Tue Oct 09 07:26:39 2012 us=600000 ERROR: could not read Auth username from stdin
Tue Oct 09 07:26:39 2012 us=600000 Exiting
Tue Oct 09 07:26:39 2012 us=600000 C:\WINDOWS\system32\route.exe DELETE 192.168.2.1 MASK 255.255.255.255 192.168.100.150
Tue Oct 09 07:26:39 2012 us=600000 Route deletion via IPAPI succeeded [adaptive]
Tue Oct 09 07:26:39 2012 us=600000 C:\WINDOWS\system32\route.exe DELETE 10.0.0.0 MASK 255.0.0.0 192.168.100.150
Tue Oct 09 07:26:39 2012 us=600000 Route deletion via IPAPI succeeded [adaptive]
Tue Oct 09 07:26:39 2012 us=600000 Closing TUN/TAP interface

どうもありがとうございました。

回答:


11

犯人はあなたの認証設定のようです。plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so login接続にクライアントが有効なユーザー名/パスワードの組み合わせを提供する必要があるを使用しています。どうやら、これは鍵の再生成時にも必要であり、OpenVPNクライアントはstdinERROR: could not read Auth username from stdin)からユーザー名を要求できないようです。

サーバー構成でreneg-secを上げても問題が解決しない理由については、これはパラメーターを両方で指定する必要があるためです-サーバーとクライアントの構成をデフォルトの3600秒(実際には1時間原因-表示されている接続を解除します)。

だからあなたの選択肢は

  • ユーザー入力を必要としない認証方法を使用します(証明書が思い浮かびます)
  • 接続の確立後にクライアントがユーザー名とパスワードの組み合わせを要求できない理由のトラブルシューティング
  • キーの再生成期間を延長するか、キーの再生成を完全に無効にします(接続のセキュリティが低下するため、問題の回避策としては劣っています)

そのとおりです。reneg-secをclient.ovpnに設定すると、この問題の解決に役立ちます。
Andrew

7

あなたはあなたの中で試すことができreneg-sec 0ますserver.conf

https://duo.com/docs/openvpn

https://tldrify.com/m80

とても簡単です。OpenVPNはデフォルトで3600秒ごとに新しいTLSセッションの再関連付けを試みるため、新しいOTPを使用して毎回再認証する必要があります。この種の動作を回避するには、openvpnにTLSセッションを再関連付けせずに既存のセッションを維持するkeepaliveように指示reneg-sec 0するだけです。ディレクティブとを組み合わせると、再関連付けがまったくなく、安定した接続が確立されます。


3

クライアント構成に「auth-nocache」オプションを追加したときも、同様の効果がありました。証明書とユーザー名+パスワードの組み合わせを使用して認証します。

openvpnが次の警告を報告していることを接続ログで数回確認しました。

警告:この設定はパスワードをメモリにキャッシュする可能性があります-これを防ぐにはauth-nocacheオプションを使用してください

だから私はこのオプションを追加して何が起こるか見てみようと思いました。さて、上記の警告は消えますが、1時間後にダイアログボックスが表示され、ユーザー名とパスワードを要求されます。

Andrewによる上記の構成にこのオプションが含まれていないことに気づいたので、なぜパスワードがキャッシュされないのかについて少し戸惑っています。多分これは、openvpnの新しいバージョンを使用しているためか、サーバーの構成でこのオプションをクライアントにプッシュするように設定できるためです。

これは、OpenVPN 2.2.1-8 + deb7u2とOpenVPN GUI v5 for Windowsで見られました。


openvpnを使用してファイルを生成してから、auth-nocacheオプションを追加する必要があります。今は完全に機能しています。生成されたファイルは次のように使用できます
crsuarezf 2015年

@ingcarlosそれがあなたのために働いていると聞いて素晴らしい。幸せなvpn-ing。
captcha

+1 Absolutley右、キャッシュディレクティブを追加しなかった後、同じ問題に直面しました。
Mohammed Noureldin 2016年
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.