ओपनवीपीएन मुद्दा - टीएलएस प्रमुख बातचीत 60 सेकंड के भीतर होने में विफल रही

14

मैं 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 क्लाइंट का आईपी है। इसलिए मैं इस बात को समझता हूं कि क्लाइंट कम से कम सर्वर तक पहुंचने में सक्षम है, इसलिए कोई रूटिंग या फ़ायरवॉल समस्या नहीं है।

मैंने यहां दिए गए विवरण का अनुसरण किया है आसान विंडोज गाइड कोई विचार?

openvpn

— vmasanas
स्रोत

1

XX.XX.XX.XXएक ही पते का प्रतिनिधित्व करने वाले दो बहुत से लोगों को मानते हुए (कृपया ऐसी बातों पर ध्यान न देने पर विचार करें ), मुझे स्रोत पोर्ट संख्या (57804, 55938) में बदलाव से दिलचस्पी है। इससे मुझे पता चलता है कि रास्ते में एक अविश्वसनीय NAT है, जो कि UDP के लिए सबसे अधिक बार होता है। क्या आप यूडीपी या टीसीपी परिवहन का उपयोग कर रहे हैं, और यदि पूर्व, आप बाद की कोशिश कर सकते हैं और देख सकते हैं कि क्या समस्या दूर हो गई है?

— MadHatter

मुझे सर्वर कंसोल पर यह संदेश दिखाई देता है जिसे मैं समझता हूं कि कम से कम क्लाइंट वहां पहुंच सकता है, इसलिए मैं मान रहा था कि NAT मुद्दा नहीं था। क्या मैं यहाँ गलत हूँ?

— वामासन

1

सभी NAT समान नहीं बने हैं। विशेष रूप से यूडीपी के लिए कुछ के पास बहुत कम समय तक रहने वाली राज्य तालिका प्रविष्टियां हैं, और ओपनवीपीएन स्रोत पोर्ट में बदलाव के लिए अच्छी तरह से नहीं लेगा। कृपया मेरे द्वारा पूछे गए प्रश्न का उत्तर दें, और यदि उपयुक्त हो, तो मेरे द्वारा सुझाए गए परिवर्तन का प्रयास करें।

— मदहैर्ट

मैं यहां अनुभव नहीं कर रहा हूं, तो क्या आप मुझे बता सकते हैं कि मैं कैसे यूडीपी या टीसीपी का उपयोग कर रहा हूं?

— वामासन

खैर, आप कोशिश कर सकते हैं man openvpnऔर प्रोटोकॉल को नियंत्रित करने वाली किसी चीज़ की तलाश कर सकते हैं । यदि आप परीक्षण करने का निर्णय लेते हैं, तो इसे क्लाइंट और सर्वर दोनों पर बदलना न भूलें।

— मदहैटर

21

क्या दिलचस्प है कि पोर्ट नंबर मध्य-धारा कैसे बदलता है:

सोम मार्च 21 11:11:47 2016 XX.XX.XX.XX: 57804 TLS: [AF_INET] XX.XX.XX.XX से प्रारंभिक पैकेट: 57804, साइड = fdf7a7ac 0264c7x3

सोम मार्च 21 11:12:38 2016 XX.XX.XX.XX: 55938 TLS: [AF_INET] XX.XX.XX.XX से प्रारंभिक पैकेट: 55938, sid = 1f242a3f e454x525

यह मुझे लगता है कि, कहीं न कहीं क्लाइंट और सर्वर के बीच, एक दुर्व्यवहार NAT डिवाइस है, एक डिवाइस जिसमें बहुत कम समय तक रहने वाली राज्य तालिका प्रविष्टियां होती हैं, जो ग्राहक के स्थापित स्ट्रीम पर लागू होने वाले स्रोत पोर्ट नंबर को बदल रही है, जिससे सर्वर को नुकसान होता है। लगता है कि दो अल्पकालिक संचार प्रगति पर हैं, एक निरंतर एक के बजाय।

इस तरह के उपकरण आमतौर पर केवल यूडीपी के साथ ऐसा करते हैं, इसलिए मैंने आपको यह पुष्टि करने की सलाह दी है कि आप यूडीपी का उपयोग कर रहे हैं, और इसके बजाय टीसीपी का प्रयास करें। यह आपने किया है, और पाया कि यह समस्या को ठीक करता है। अगला कदम दुर्व्यवहार करने वाले NAT डिवाइस की पहचान करना है, इसे एक क्लब हथौड़ा से मारा है, और इसे एक के साथ बदलें जो यह मानने की कार्डिनल गलती नहीं करता है कि सभी UDP संचार अल्पकालिक हैं; लेकिन आपने संकेत दिया है कि आप टीसीपी में एक बदलाव के रूप में बदलने से खुश हैं, और इसलिए यह मामला समाप्त हो गया है।

— मैड हैटर
स्रोत

2

आपकी ईगल आंख के लिए +1!

— डायमंड

@ बांगल क्यों, धन्यवाद! शैतान का अधिकांश विवरण इस व्यवसाय में है।

— 10

हां, मुझे पता है, लेकिन मैंने इसे याद किया और केवल आपके कहने के बाद इसे देखा। निश्चित था कि यह एक फ़ायरवॉल समस्या है।

— डायमंड

खैर, यह है, तो आप सही थे। और अपने आप को मत मारो, आप अगली बार कठिन लगेंगे!

— MadHatter

क्या टीसीपी के बजाय यूडीपी का उपयोग करने पर कोई लाभ है? टीसीपी अब मेरे लिए काम कर रही है, जब तक कि इसके साथ कोई नकारात्मक पहलू नहीं है।

— वामासन

3

यह Openvpn स्थापित करने में सबसे आम त्रुटि में से एक है और इसके लिए एक FAQ प्रविष्टि है। मैं इसे यहाँ उद्धृत करने जा रहा हूँ:

टीएलएस त्रुटि: टीएलएस महत्वपूर्ण बातचीत 60 सेकंड के भीतर होने में विफल रही (अपने नेटवर्क कनेक्टिविटी की जांच करें)

OpenVPN को स्थापित करने में सबसे आम समस्याओं में से एक यह है कि कनेक्शन के दोनों तरफ दो OpenVPN डेमन्स एक दूसरे के साथ एक टीसीपी या यूडीपी कनेक्शन स्थापित करने में असमर्थ हैं।

यह लगभग इसका परिणाम है:

सर्वर के नेटवर्क पर एक परिधि फ़ायरवॉल आने वाले OpenVPN पैकेटों को फ़िल्टर कर रहा है (डिफ़ॉल्ट रूप से OpenVPN UDP या TCP पोर्ट नंबर 1194 का उपयोग करता है)।

OpenVPN सर्वर मशीन पर चलने वाला एक सॉफ्टवेयर फ़ायरवॉल पोर्ट 1194 पर आने वाले कनेक्शन को फ़िल्टर कर रहा है। ध्यान रखें कि कई OS डिफ़ॉल्ट रूप से आने वाले कनेक्शन को ब्लॉक कर देंगे, जब तक कि अन्यथा कॉन्फ़िगर न किया जाए।

सर्वर के नेटवर्क पर NAT गेटवे के पास OpenVPN सर्वर मशीन के आंतरिक पते पर TCP / UDP 1194 के लिए पोर्ट फॉरवर्ड नियम नहीं है।

OpenVPN क्लाइंट कॉन्फिगरेशन का कॉन्फिगर फाइल में सही सर्वर एड्रेस नहीं होता है। क्लाइंट कॉन्फ़िग फ़ाइल में दूरस्थ निर्देश सर्वर या तो या सर्वर नेटवर्क गेटवे के सार्वजनिक IP पते को इंगित करना चाहिए।

एक और संभावित कारण यह है कि विंडोज़ फ़ायरवॉल ओपनवपन .n बाइनरी के लिए पहुंच को अवरुद्ध कर रहा है। आपको काम करने के लिए OpenVPN के लिए इसे श्वेतसूची ("अपवाद" सूची में जोड़ें) की आवश्यकता हो सकती है।

यह अत्यधिक संभावना है कि इनमें से कोई भी आपके मामले में भी यही समस्या पैदा कर रहा है। तो बस इसे हल करने के लिए एक-एक करके सूची से गुजरें।

Ref: TLS त्रुटि: TLS कुंजी बातचीत 60 सेकंड के भीतर होने में विफल रही (अपने नेटवर्क कनेक्टिविटी की जाँच करें)

— हीरा
स्रोत

मैं इन बिंदुओं से गुजरा हूँ, लेकिन यकीन नहीं होता कि मैं कुछ याद कर रहा हूँ: 1. इस समय फ़ायरवॉल क्लाइंट और सर्वर दोनों में बंद हैं, 2. वही, 3. राउटर का सर्वर के लिए एक अग्रेषण नियम है और मैं इसे देखता हूँ सर्वर कंसोल पर दिखाई दे रहा ट्रैफ़िक, 4.client का सही IP पता है, 5. कोई फ़ायरवॉल नहीं जो मैं बता सकता हूँ।

— वामासन

खैर, ईमानदारी से मैं फिलहाल कुछ और नहीं सोच सकता। यह सुनिश्चित करने के लिए कि विंडोज़ सर्वर में नेटवर्क कॉन्फ़िगरेशन कैसे है? यह संयोग से कई प्रवेश द्वार है? क्या यह डिफ़ॉल्ट गेटवे है जो राउटर को इंगित किया गया है? यदि हाँ, तो बाकी परीक्षण आप कर सकते हैं, जैसा कि MadHatter ने सुझाव दिया था, tcp के साथ परीक्षण करने के लिए।

— डायमंड

अगर किसी को लगता है कि एक हाथ उधार देने जैसा है, तो मैंने यहां (अभी तक) TLS हैंडशेक विफलता प्रश्न पोस्ट किया है: serverfault.com/questions/867599/…

— Ola Tuvesson

दूसरी बात यह है कि दोनों मेजबानों के बीच उच्च विलंबता है । मैं बस इस पर बड़े पैमाने पर अपना सिर खुजला रहा था, और कुछ गॉडफॉर्स्ड कारण से मुझे एक दिशा में 6000ms + पिंग राउंड ट्रिप मिल रही थी (क्लाइंट से सर्वर), लेकिन दूसरे तरीके से नहीं। यह 60 से अधिक लेने के लिए महत्वपूर्ण बातचीत का कारण बन रहा था। मेरे आईएसपी द्वारा प्रदान किए गए राउटर को रिबूट करने से समस्या हल हो गई। शायद एक दुर्लभ किनारा मामला है, लेकिन उम्मीद है कि किसी को बाहर करने में मदद करता है।

— s.co.tt

3

मुझे इस तरह से टीएलएस की महत्वपूर्ण बातचीत के समय मिल रहे थे। लेकिन मेरे मामले में मुझे एहसास हुआ कि दूरस्थ लिंक एक स्थानीय आईपी पता था।

हमारे pfSense फ़ायरवॉल पर वीपीएन को गलती से WAN इंटरफ़ेस के बजाय LAN इंटरफ़ेस पर डाल दिया गया था, और इसलिए निर्यात किए गए कॉन्फ़िगरेशन को फ़ायरवॉल के LAN IP पते से कनेक्ट करने और कनेक्ट करने के लिए सेट किया गया था - जो क्लाइंट के साथ स्वाभाविक रूप से काम करने वाला नहीं था। एक अलग लैन।

मुझे लगता है कि इस से मुख्य takeaways हैं:

एक महत्वपूर्ण बातचीत समय समाप्त होने का मतलब यह नहीं है कि आप किसी भी चीज़ से जुड़ने में कामयाब रहे हैं।

तो इस स्तर पर यह अभी भी जाँच के लायक हो सकता है कि आप वास्तव में सही जगह से जुड़ रहे हैं, और कनेक्शन को अवरुद्ध करने के लिए कोई फ़ायरवॉल नियम नहीं हैं, आदि विशेष रूप से यदि आपका कॉन्फ़िगरेशन स्वचालित रूप से उत्पन्न हुआ है।

ध्यान दें कि लॉगिन प्रॉम्प्ट प्राप्त करने का अर्थ यह नहीं है कि आप कनेक्ट हैं , क्योंकि OpenVPN कनेक्ट करने का प्रयास करने से पहले आपकी साख के लिए पूछता है।
सुनिश्चित करें कि आपका वीपीएन सर्वर सही इंटरफेस पर सुन रहा है।

(बेशक, यह कई सर्वर-साइड मिसकॉन्फ़िगरेशनों में से एक है जो हो सकता है, जैसे कि फ़ायरवॉल नियम, गलत पोर्ट नंबर डालना, टीसीपी और यूडीपी को रोकना, आदि)

— mwfearnley
स्रोत

1

मेरे पास एक ही त्रुटि थी और किसी भी सलाह ने मदद नहीं की, सब कुछ ठीक लग रहा था: आईपी, पोर्ट, फ़ायरवॉल, सब कुछ। 2 घंटे के लिए पागल हो गया।

समाधान क्लाइंट कॉन्फिगरेशन में यूडीपी से टीसीपी में प्रोटोकॉल को बदलना था (जाहिर है कि मैं यूडीपी को लंबे समय पहले अक्षम कर चुका था)।

आशा है कि यह किसी की मदद करता है :)

LE: इससे मेरी समस्या हल हो गई, लेकिन यह टिप्पणी के अनुसार सबसे अच्छा तरीका नहीं है। आपको टीसीपी के बजाय यूडीपी का उपयोग करना चाहिए। इसने मेरी मदद की क्योंकि क्लाइंट और सर्वर कॉन्फिगर के बीच मेरी अलग-अलग सेटिंग थी।

— BOSCH
स्रोत

आपको पता होना चाहिए कि टीसीपी के अंदर टीसीपी को इनकैप्सुलेट करने से बहुत खराब प्रदर्शन की समस्या होती है, दोनों टीसीपी स्टैक के कारण एक-दूसरे के साथ प्रतिस्पर्धा करने की कोशिश करते हैं।

— ईएएए

दरअसल, यह बकवास की तरह काम करता है। हालाँकि मुझे समझ नहीं आया कि आपने क्या कहा, प्रदर्शन बहुत खराब है। क्या मुझे UDP पर स्विच करना चाहिए?

— बोस

2

हाँ। UDP वीपीएन कार्यान्वयन के लिए मानक है, अच्छे कारण के लिए। टीसीपी में त्रुटि-सुधार की कार्यक्षमता है - खोए हुए पैकेटों को फिर से प्रसारित करने की क्षमता, आदि। यदि आप टीसीपी के अंदर टीसीपी को घेरते हैं, और आप पैकेट नुकसान, दोनों टीसीपी स्टैक ("अंदर" ट्रैफ़िक के साथ-साथ एन्क्रिप्टेड ओपनवीपीएन ट्रैफ़िक) को भी बाधित करते हैं। खोए हुए पैकेट के लिए प्रयास करें और सही करें। जब आप UDP में TCP को एनकैप्सुलेट करते हैं, तो यह कोई समस्या नहीं है - केवल अंदर का ट्रैफ़िक पुनः प्रयास करेगा।

— ईईएए

संकेत के लिए और स्पष्टीकरण के लिए धन्यवाद। मैंने यूडीपी पर स्विच किया और कनेक्शनों पर नजर रखी। इसके अलावा, मुझे स्टैक के बारे में कुछ और पढ़ने की जरूरत है ...

— बोस

टीसीपी पर टीसीपी क्यों एक बुरा विचार है, यह समझाने में सहायक पृष्ठ: sites.inka.de/bigred/devel/tcp-tcp.html

— mwfearnley

1

ध्यान दें कि आप ओपन वीपीएन सर्वर से जुड़े बिना - या यहां तक कि किसी भी चीज़ से सफलतापूर्वक कनेक्ट होने के बिना, टीएलएस की महत्वपूर्ण बातचीत त्रुटि प्राप्त कर सकते हैं !

मैंने स्थानीय वीपीएन से कनेक्ट करने के लिए एक वीपीएन कॉन्फिगरेशन को संशोधित किया, एक पोर्ट पर जो कुछ भी नहीं सुन रहा था:

OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] 26 अप्रैल 2018 को बनाया गया
विंडोज संस्करण 6.2 (विंडोज 8 या अधिक) 64 बिट
पुस्तकालय संस्करण: ओपनएसएसएल 1.1.0h 27 मार्च 2018, एलजेडओ 2.10
टीसीपी / यूडीपी: हाल ही में उपयोग किए गए दूरस्थ पते को संरक्षित करना: [AF_INET] 127.0.0.1:12345
UDP लिंक लोकल (बाउंड): [AF_INET] [अपरिभाषित]: 0
UDP लिंक रिमोट: [AF_INET] 127.0.0.1:12345 
TLS त्रुटि: TLS कुंजी बातचीत 60 सेकंड के भीतर होने में विफल रही (अपने नेटवर्क कनेक्टिविटी की जाँच करें)
टीएलएस त्रुटि: टीएलएस हैंडशेक विफल
SIGUSR1 [सॉफ्ट, tls-error] प्राप्त हुआ, प्रक्रिया पुनः आरंभ
...

त्रुटि आपको एक गलत समझ में डाल सकती है जो आप वीपीएन सर्वर से बात कर रहे हैं।

आप पहले भी क्रेडेंशियल के लिए प्रेरित हो सकते हैं, लेकिन आपके कंप्यूटर के बाहर कुछ भी वास्तव में उनके लिए नहीं पूछा है।

— mwfearnley
स्रोत

1

पहले बताए गए समाधानों में से कोई भी काम नहीं किया। मेरे मामले में, भले ही क्लाइंट लॉग में वही त्रुटि दिखाई दी हो 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

— mpprdev
स्रोत

0

मैं AWS में इस त्रुटि में भाग गया, जहां OpenVPN एक सार्वजनिक IP के साथ सर्वर पर स्थापित किया गया था, लेकिन एक उदाहरण पर जो एक निजी सबनेट में था, यानी एक सबनेट जिसमें इंटरनेट गेटवे के लिए एक मार्ग नहीं था।

एक बार जब मैंने एक सार्वजनिक सबनेट के भीतर एक सर्वर पर OpenVPN तैनात किया, तो यह सब अच्छी तरह से काम किया :)

AWS में सार्वजनिक / निजी सबनेट पर: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html

— Zoltán
स्रोत

0

मुझे भी TLS key negotiation failed to occur within 60 secondsसमस्या आई।

आधिकारिक सुझाव से, Diamant पोस्ट के रूप में, नेटवर्क कनेक्शन में कुछ गलत होना चाहिए। हालाँकि, न तो फ़ायरवॉल और न ही NAT समस्या का कारण बनता है।

मेरे मामले में, मैंने सबसे पहले कनेक्शन की जाँच की nc -uvz xxx.xxx.xxx.xxx 1194। लिंक ठीक है।

इसके अलावा, एक ही LAN के भीतर कई अन्य vpn क्लाइंट ठीक काम करते हैं।

कहीं से मैंने देखा कि udp कनेक्शन में प्रतिक्रिया या पोर्ट आगे की कुछ समस्याएं हैं।

इसलिए मैं चल रहे vpn क्लाइंट को सबसे बड़े आईपी से हैंगिंग क्लाइंट, जैसे "10.8.0.100" से "10.8.0.50" तक रोक देता हूं।

फिर रुके हुए vpn क्लाइंट को रिवर्स में शुरू करें।

बैंग! सभी vpn क्लाइंट प्रोपर तरीके से काम करते हैं।

अंत में, एक मौका होता है TLS key negotiation failed to occur within 60 secondsसमस्या यह है कि एक गलत अनुक्रम में एक लैन के भीतर कई वीपीएन क्लाइंट।

— samson.wang
स्रोत

1

यह स्पष्ट नहीं है कि यह मूल प्रश्न में समस्या से कैसे संबंधित है।

— वार्ड - को पुनः स्थापित मोनिका

0

एक संभावित कारण यह है कि यदि सर्वर को नए सिरे से टीएलएस संस्करण की आवश्यकता होती है तो क्लाइंट द्वारा समर्थित टीएलएस को। यानी 1.2 बनाम 1.0।

कोशिश करने के लिए स्पष्ट बात OpenVPN क्लाइंट को अपडेट करना है, या TLS 1.0 को स्वीकार करने के लिए सर्वर पक्ष को संशोधित करना है।

— ozk
स्रोत