প্রতি ঘন্টা ওপেনভিপিএন সার্ভার থেকে সংযোগ বিচ্ছিন্ন করা


13

আমার OpenVPNকনফিগারেশনটি নিয়ে আমি বরং একটি অদ্ভুত সমস্যা পাচ্ছি । আমি Windows 7সরকারী সর্বশেষ OpenVPNক্লায়েন্টের সাথে আমার OpenVPNসার্ভারে সংযোগ দিচ্ছি ( OpenVPN 2.1.4 i386-redhat-linux-gnu)।

সমস্যাটি হল আমি OpenVPNঠিক 1 ঘন্টা পরে আমার সার্ভার থেকে সংযোগ বিচ্ছিন্ন হয়ে যাচ্ছি এবং এর জন্য কী নির্দেশ / বিকল্পটি প্রতিক্রিয়াযোগ্য তা আমি বুঝতে পারি না। হতে পারে এটি একটি ক্লায়েন্ট সমস্যা? আমি বিভিন্ন Windowsসিস্টেম এবং Windows VPNক্লায়েন্ট চেষ্টা করেছি । Linuxক্লায়েন্ট কোন সংযোগ বিচ্ছিন্ন সঙ্গে প্রত্যাশিত কাজ করছে।

আপনি কি দয়া করে আমাকে এই সমস্যাটি সমাধান করতে সহায়তা করতে পারেন? আমি বই এবং গুগলিং পড়ার চেষ্টা করেছি এবং কিছু লোকেরা খেলতে keepaliveএবং reneg-secনির্দেশনা দেওয়ার পরামর্শ দেয় । তবে তাতে কোনও সাহায্য বলে মনে হচ্ছে না।

ওপেনভিপিএন সার্ভার কনফিগারেশন

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"

সার্ভার লগ (রিনিট_সিআরসি = 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

আপনাকে অনেক ধন্যবাদ.

উত্তর:


12

অপরাধী আপনার প্রমাণীকরণের কনফিগারেশন বলে মনে হচ্ছে। আপনি ব্যবহার করছেন plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so loginযা সংযোগের জন্য ক্লায়েন্টের একটি বৈধ ব্যবহারকারীর নাম / পাসওয়ার্ড সংমিশ্রণ সরবরাহ করতে হবে। স্পষ্টতই, এটি পুনরুদ্ধার করার জন্যও আবশ্যক এবং আপনার ওপেনভিপিএন ক্লায়েন্টটি stdin( ERROR: could not read Auth username from stdin) থেকে ব্যবহারকারীর নামের জন্য অনুরোধ করতে অক্ষম বলে মনে হচ্ছে ।

আপনার সার্ভারের কনফিগারেশনে রেগ-সেকেন্ড বাড়ানোর কারণগুলিতে যে কোনও কারণেই সহায়তা করে না, এটি কারণ হ'ল প্যারামিটারটি উভয়ই নির্দিষ্ট করতে হবে - সার্ভারের এবং ক্লায়েন্টের কনফিগারেশনটি কার্যকরভাবে 3600 সেকেন্ডের ডিফল্টের উপরে উঠানো হবে (যা ঘটে এক ঘন্টা সৃষ্টি করুন - আপনি যে সংযোগটি দেখছেন তা সংযোগ দিন)।

সুতরাং আপনার বিকল্পগুলি হবে

  • একটি প্রমাণীকরণ পদ্ধতি ব্যবহার করুন যার ব্যবহারকারীর ইনপুট প্রয়োজন হয় না (শংসাপত্রগুলি মনে মনে বসন্ত)
  • কেন আপনার ক্লায়েন্ট সংযোগ স্থাপনের পরে ব্যবহারকারীর নাম / পাসওয়ার্ড সংমিশ্রনের জন্য অনুরোধ জানাতে অক্ষম তা সমস্যা সমাধান করুন
  • রেকিংয়ের সময়কাল বাড়ান বা পুরোপুরি রিকিং নিষ্ক্রিয় করুন (এটি আপনার সংযোগের সুরক্ষাকে দুর্বল করে তোলে, সুতরাং এটি অবশ্যই আপনার সমস্যার থেকে নিকৃষ্টতম কাজ)

আপনি ঠিক বলেছেন, ক্লায়েন্টকে নতুন করে সেকেন্ড রেখে এই সমস্যাটি সমাধান করতে সহায়তা করেছে ov
অ্যান্ড্রু

8

আপনি চেষ্টা করতে পারেন reneg-sec 0আপনার server.conf:

https://duo.com/docs/openvpn

https://tldrify.com/m80

এটা সত্যিই বেশ সহজ। যেহেতু ওপেনভিপিএন ডিফল্টরূপে প্রতি ৩০০০০ সেকেন্ডে একটি নতুন টিএলএস সেশনটি পুনরায় আলোচনা করার চেষ্টা করে, আপনাকে নতুন ওটিপি ব্যবহার করে প্রতিবার পুনরায় প্রমাণীকরণ করতে হবে। এই ধরণের আচরণ এড়াতে, ওপেনপিপিএনকে কেবল কোনও টিএলএস অধিবেশন পুনর্বিবেচনা না করার এবং বিদ্যমান keepaliveনির্দেশকে জীবিত রাখার কথা বলার বিষয়, যদি আপনি নির্দেশকে একত্রিত করেন এবং reneg-sec 0, আপনার কোনও স্থিতিশীল সংযোগ থাকবে, যা কোনও পুনর্বিবেচনা না করে।


3

আমি যখন আমার ক্লায়েন্ট কনফিগারেশনে 'auth-nocache' বিকল্পটি যুক্ত করেছি তখন আমি একইরকম প্রভাব অনুভব করেছি। আমি শংসাপত্রগুলি ব্যবহার করি এবং প্রমাণীকরণের জন্য একটি ব্যবহারকারীর নাম + পাসওয়ার্ড সংমিশ্রণ করি।

কয়েকবার আমি সংযোগ লগগুলিতে লক্ষ্য করেছি যে ওপেনভিপিএন নিম্নলিখিত সতর্কতাটি জানিয়েছে:

সতর্কতা: এই কনফিগারেশন মেমোরিতে পাসওয়ার্ডগুলি ক্যাশে করতে পারে - এটি প্রতিরোধের জন্য auth-nocache বিকল্পটি ব্যবহার করুন

সুতরাং আমি ভেবেছিলাম আমি কেবল এই বিকল্পটি যুক্ত করব এবং দেখুন কী ঘটে। ঠিক আছে, উপরের সতর্কতাটি চলে যাবে না, তবে এক ঘন্টা পরে একটি ডায়ালগ বক্স পপ আপ করে, আমাকে আমার ব্যবহারকারীর নাম এবং পাসওয়ার্ড জিজ্ঞাসা করল।

আমি লক্ষ্য করেছি যে অ্যান্ড্রু দ্বারা উল্লিখিত উপরের কনফিগারেশনটিতে এই বিকল্পটি নেই তাই আমি পাসওয়ার্ডটি কেন ক্যাশে করে না সে সম্পর্কে আমি কিছুটা বিস্মিত। সম্ভবত এটি হ'ল কারণ আমি ওপেনভিপিএন-র একটি নতুন সংস্করণ ব্যবহার করছি বা ক্লায়েন্টের কাছে এই বিকল্পটি চাপানোর জন্য এটি সার্ভার কনফিগারেশনে সেট করা যেতে পারে।

এটি দেখা গিয়েছিল: উইন্ডোজের জন্য ওপেনভিপিএন জিইউআই ভি 5 সহ ওপেনভিপিএন 2.2.1-8 + deb7u2।


আমাকে ওপেনভিপিএন ব্যবহার করে একটি ফাইল তৈরি করতে হবে এবং তারপরে লেখক-নোকাস বিকল্পটি যুক্ত করতে হবে। এখন নিখুঁতভাবে কাজ করছে। উত্পন্ন ফাইলটি হিসাবে ব্যবহার করা যেতে পারে
crsuarezf

আপনার জন্য কাজ করছে শুনে ইংকার্লোস দুর্দান্ত। শুভ ভিপিএন-ইন
ক্যাপচা

+1 অবসোল্টলি ঠিক আছে, কোনও ক্যাশে নির্দেশ না দেওয়ার পরে আমি একই সমস্যার মুখোমুখি হয়েছি।
মোহাম্মদ নুরাল্ডিন
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.