एकाच होस्टवर OpenVPN सर्व्हर आणि क्लायंट: क्लायंट का गळून पडतात

ज्या मशीनवर आधीच VPN सर्व्हर चालतो तिथे क्लायंट प्रोफाइल जोडा, आणि पहिले नुकसान मूळ सेवेचे होईल। नवीन टनेल कधीच स्थापित होणार नाही, किंवा ते वर येईल आणि सर्व्हरचे विद्यमान क्लायंट शांतपणे उत्तरे मिळवणे थांबवतील। दोन टकरी या दोन्ही निकालांचे कारण आहेत: आधीच वापरात असलेला टनेल पूल, आणि नवीन क्लायंट-अर्ध्याने बसवलेला डीफॉल्ट रूट जो संपूर्ण तक्ता व्यापतो। यापैकी कोणतेही OpenVPN त्रुटी संदेश देत नाही, म्हणून बिघाड सर्व्हरची समस्या म्हणून वाचला जातो।

एक मशीन, दोन भूमिका, आणि उत्तरे कुठे जायला हवीत याबद्दल दोन विसंगत उत्तरे।

एकच पूल, दोन सर्व्हर: कोण जिंकतो

प्रत्येक सर्व्हर उदाहरणाला स्वतःचे टनेल सबनेट हवे। server 10.8.0.0 255.255.255.0 सारखी ओळ दुसऱ्या कॉन्फिगरेशनमध्ये कॉपी केल्यास दोन्ही उदाहरणांना एकच प्रिफिक्स मिळतो, आणि निकाल एकतर सुरू होण्यास नकार किंवा एका सर्व्हरचे क्लायंट दुसरेही आपले मानत असलेले पत्ते मिळवणारी शांत स्पर्धा। वेगळे UDP पोर्ट आणि वेगळी उपकरण नावे उपयोगी नाहीत, कारण दोन्हीपैकी कोणीही पत्ता-जागेला स्पर्श करत नाही। दुसरा पूल बदला, आणि रूट जिथे जिथे त्याचा उल्लेख करतात तिथे तिथे बदला।

संपादनापूर्वी काय सक्रिय आहे त्याची यादी करा: ip -4 addr show टनेल उपकरणांची यादी देतो, ss -lunp ऐकणाऱ्यांची यादी देतो, आणि systemctl list-units युनिटची नावे सांगतो। टनेल पत्त्यांवर एक नजर पूल टकरीतात की नाही हे ठरवते।

क्लायंट प्रोफाइल तक्त्यात काय जोडते

क्लायंट-अर्धा जोडला जाताच रूट लिहितो। redirect-gateway def1 डीफॉल्ट रूटला 0.0.0.0/1 अधिक 128.0.0.0/1 मध्ये विभागतो, दोन्ही नवीन उपकरणातून रूट होतात, शिवाय दूरच्या सर्व्हरकडे जाणारा होस्ट रूट जो मुद्दाम भौतिक इंटरफेसला पिन केलेला असतो। हा पिन टनेलला स्वतःच्या वाहतुकीसाठी मार्ग ठेवण्यासाठी आहे। बाकी सर्व, स्थानिक सर्व्हर आपल्या क्लायंटना द्यायच्या उत्तरांसह, आता नवीन डीफॉल्टचे अनुसरण करते आणि दूरच्या दुव्यातून बाहेर जाते।

म्हणून दुसरी टकरी तुटलेला टनेल नाही। तो तक्त्यातल्या चुकीच्या जागी असलेला कार्यरत टनेल आहे।

भूमिका वेगळ्या ठेवण्याचे तीन मार्ग

सर्वात कमी हस्तक्षेपाचा उपाय डीफॉल्ट रूट क्लायंट प्रोफाइलबाहेर ठेवतो: दूरच्या प्रिफिक्ससाठी route-nopull अधिक स्पष्ट route ओळी, म्हणजे स्थानिक तक्ता फक्त तिथेच बदलतो जिथे तुम्ही मागितले। पुढचे पाऊल स्थानिक टनेल सबनेटला सूट देणारा धोरण-नियम आहे, ज्यामुळे डीफॉल्ट रूट असतानाही स्थानिक क्लायंटना उत्तरे ज्या इंटरफेसवर आली त्याच इंटरफेसवरून बाहेर जातात। सर्वात सखोल उपाय म्हणजे क्लायंट भूमिकेसाठी वेगळी नेटवर्क नेमस्पेस, जी सामायिक तक्ता पूर्णपणे काढून टाकते आणि सांभाळण्यासाठी दुसरा राउटिंग संदर्भ मागते।

कोणताही मार्ग घेतला तरी अपवादात LAN नाही, स्थानिक टनेल सबनेटचे नाव असावे। स्थानिक सर्व्हर पाठवतो त्या उत्तराचे गंतव्य टनेल पत्ता असतो, म्हणून LAN-आकाराचा अपवाद त्याला कधीच जुळत नाही।

दोन उदाहरणांपैकी कोणते दोषी आहे

क्लायंट उदाहरण थांबवा आणि मूळ क्लायंट पुन्हा तपासा। तात्काळ सुधारणा म्हणजे राउटिंग, सर्व्हर नाही। क्लायंट परत आणा आणि ip route get ने एकच उत्तर ट्रेस करा, ज्याला स्रोत आणि गंतव्य दोन्ही पत्ते दिले आहेत, जे कर्नेल निवडेल तो मार्ग दाखवते, नंतर tcpdump -ni any port 1194 ने पॅकेट प्रत्यक्षात कोणता इंटरफेस वापरतात ते पहा। सर्व्हरची स्टेटस फाइल, दर काही सेकंदांनी status निर्देशाद्वारे लिहिली जाते, जोडलेल्या क्लायंटची यादी आणि दोन्ही दिशांचे बाइट काउंटर घेऊन जाते।

त्या काउंटर एकमेकांच्या विरुद्ध वाचा। जो रहदारी बाहेर जाते आणि कधीच परत येत नाही तो हँडशेकचा प्रश्न नाही, राउटिंगचे उत्तर आहे।