जेव्हा OpenVPN चा सर्व्हर त्याच होस्टवर चालतो तेव्हा क्लायंट अडकतो

माझ्याकडे एक लॅब मशीन होती जी दूरच्या साइटवरून टनेल स्वीकारत होती आणि त्याच वेळी विक्रेत्याच्या नेटवर्कवर डायल करत होती। आउटबाउंड प्रोफाइल आठवड्यांपासून काम करत होते। इनबाउंड सर्व्हर जोडल्यानंतर, आउटबाउंड जोडले आणि नंतर काही सेकंदात ट्राफिक पास करणे थांबवले, किंवा पत्ता आधीच वापरात आहे या त्रुटीसह सुरू होण्यास नकार दिला। कॉन्फिग फाइल्स बदलल्या नव्हत्या; होस्टला फक्त पोर्ट आणि रूटबद्दल स्वतःचे मत असलेली दुसरी OpenVPN प्रक्रिया मिळाली होती।

अपयश यादृच्छिक नाही आणि ती प्रमाणीकरणाची समस्या नाही। एका मशीनवरील दोन डेमन एकाच स्थानिक सॉकेट आणि त्याच रूटिंग टेबलसाठी स्पर्धा करतात, आणि जे शेवटी सुरू होते किंवा पुन्हा जोडले जाते ते सहसा जिंकते। या दोन टक्करांपैकी तुमच्याकडे कोणती आहे हे जाणून घेणे प्रथम कुठे पाहावे हे ठरवते।

लक्षण उलट्या क्रमाने वाचा

टनेल कधी मरते यापासून सुरुवात करा। सुरुवातीला बाइंड त्रुटी ऐकणाऱ्या बाजूकडे निर्देश करते: काहीतरी आधीच त्या पोर्टचे मालक आहे, आणि OpenVPN तो सामायिक करण्याऐवजी सुरू होण्यास नकार देते। वर येऊन नंतर शांत होणारे टनेल रूटिंगकडे निर्देश करते, कारण दुसऱ्या इन्स्टन्सने स्थापित केलेला रूट बाह्य कनेक्शनच्या पॅकेट्सना त्यांच्या मार्गावरून ओढू शकतो।

दोन्ही प्रकरणे समान वापरकर्ता तक्रार निर्माण करतात, म्हणूनच पुनर्प्रयत्न लूप आणि वॉचडॉग स्क्रिप्ट काहीही दुरुस्त करत नाहीत। ते क्लायंटला पुन्हा त्याच संघर्षात जोडतात। पहिला उपयुक्त प्रश्न असा आहे की ट्राफिक थांबते तेव्हा प्रक्रिया अजूनही चालू आहे का।

प्रत्येक इन्स्टन्ससाठी एक सॉकेट आणि एक उपकरण

ऐकणारा सर्व्हर त्याचा पोर्ट बाइंड करतो; आउटबाउंड क्लायंटलाही त्याच्या एन्कॅप्स्युलेटेड ट्राफिकसाठी स्थानिक पोर्ट आवश्यक असतो। जेव्हा दोन्ही एकाच होस्टवर राहतात, तेव्हा क्लायंटचे डीफॉल्ट वर्तन सर्व्हरच्या पोर्टशी टक्कर देऊ शकते। क्लायंटचा स्थानिक पोर्ट पिन केला जाऊ शकतो, आणि जिथे साथीदाराला निश्चित स्रोत पोर्टची आवश्यकता नाही तिथे बाइंडिंग वगळली जाऊ शकते:

lport 1195
nobind
dev tun1

ती संख्या उदाहरणे आहेत, अट नाही। महत्त्वाचे म्हणजे क्लायंट सर्व्हरच्या पोर्टसाठी स्पर्धा करणे थांबवतो आणि प्रत्येक इन्स्टन्सला वेगळे टनेल उपकरण मिळते। tun0 सामायिक करणारे दोन डेमन, त्यांचे पोर्ट वेगळे असले तरी, एकमेकांची उपकरण स्थिती ओव्हरराइट करतात, म्हणून प्रत्येक टनेलसाठी एक उपकरण ऐच्छिक नाही।

nobind क्लायंट बाजूचे आहे। सर्व्हरला अजूनही बाइंड आणि ऐकणे आवश्यक आहे, म्हणून ओळ सर्व्हर कॉन्फिगमध्ये कॉपी करू नका, आणि ज्या क्लायंटचा साथीदार निश्चित स्रोत पोर्टवर फिल्टर करतो त्यावर बाइंडिंग बंद करू नका।

डीफॉल्ट रूटसाठी एक मालक निवडा

फक्त एकच कनेक्शन डीफॉल्ट रूट स्थापित करू शकते। जर दोन्ही प्रोफाइल सर्व ट्राफिक रीडायरेक्ट करत असतील, तर दुसरे कनेक्शन पहिल्याला शांतपणे बदलते, आणि पहिले तुटलेले दिसते। एकतर आउटबाउंड टनेल विभाजित ठेवा आणि फक्त विक्रेत्याचे प्रीफिक्स पाठवा, किंवा त्याला वेगळे रूटिंग टेबल द्या।

ip rule add from 10.9.0.2 table 120
ip route add default dev tun1 table 120
ip route get 10.9.0.2

वरील पत्ते आणि टेबल क्रमांक प्लेसहोल्डर आहेत। नियम जोडल्यानंतर लगेच, VPN सर्व्हरचा स्वतःचा पत्ता अजूनही सामान्य टेबलद्वारे सोडवला जातो याची खात्री करा; बाह्य ट्रान्सपोर्ट पकडणारे टेबल ते ज्या टनेलचे संरक्षण करायचे होते ते तोडते, आणि त्यानंतरचा पुन्हा कनेक्ट लूप अविश्वासार्ह प्रदात्यासारखा दिसतो।

पुन्हा कनेक्ट आणि रीबूट टिकून राहण्यासाठी आवश्यक असलेल्या सेटअपसाठी, नेटवर्क नेमस्पेस ही अधिक मजबूत सीमा आहे। दुसरा क्लायंट स्वतःच्या नेमस्पेसमध्ये स्वतःच्या इंटरफेस आणि रूटसह चालतो, आणि सीमा ओलांडण्याची आवश्यकता असलेल्या सेवाच उघड केल्या जातात। होस्ट एक डीफॉल्ट रूट ठेवतो, आणि नेमस्पेसचे पुन्हा कनेक्शन तो पुन्हा लिहू शकत नाही।

स्टेटस लाइनने नाही, टेबलने तपासा

जोडले आहे असे नोंदवणारा क्लायंट फक्त त्याचे नियंत्रण चॅनेल सिद्ध करतो। प्रत्येक कनेक्शनपूर्वी आणि नंतर रूटिंग स्थिती कॅप्चर करा, नंतर कर्नेलला विचारा की वास्तविक गंतव्य कोणते उपकरण वापरेल:

ip route show
ip route get 10.40.0.20
ss -lunp | grep 1194

दुसरे टनेल सुरू होताना विक्रेत्याच्या पत्त्यासाठी निवडलेले उपकरण बदलल्यास, तुमच्याकडे रूट टक्कर आहे। दोन्ही प्रक्रिया एकाच स्थानिक पोर्टवर दिसल्यास, तुमच्याकडे सॉकेट टक्कर आहे। दुसऱ्याशिवाय पहिले दुरुस्त केल्याने अपयश फक्त पुढील पुन्हा कनेक्शनकडे सरकते।

पोर्ट, उपकरणे, टेबल आणि रूट मालक होस्टच्या रनबुकमध्ये लिहा। अन्यथा तिसरे टनेल जोडणारी पुढील व्यक्ती तीच टक्कर पुन्हा शोधेल, आणि दिसणारा एकमेव पुरावा म्हणजे दुसऱ्या कोणाचा डेमन रीस्टार्ट होईपर्यंत चालणारे कनेक्शन।