fwmark सह एकाच Linux होस्टवर दोन OpenVPN क्लायंट जोडा

एकाच Linux होस्टवर दुसरा OpenVPN क्लायंट जोडणे दोनपैकी एका ठिकाणी अयशस्वी होते. एकतर आतील क्लायंट आपल्या सर्व्हरपर्यंत पोहोचू शकत नाही कारण बाहेरील टनेलने ते वहन ताब्यात घेतले आहे, किंवा दुसरा क्लायंट रूट टेबल पुन्हा लिहितो आणि पहिले टनेल काम करणे थांबवते. दोन्ही समस्या राउटिंगमध्ये आहेत, एन्क्रिप्शनमध्ये नाही, आणि दोन्ही नव्या टनेलने कोणताही अनुप्रयोग रहदारी वाहून नेण्यापूर्वी सोडवल्या जातात. येथील पत्ते उदाहरणासाठी आहेत: tun0 बाहेरील टनेल आहे, 203.0.113.9 आतील सर्व्हर आहे, आणि TCP 9999 हा फ्लो आहे ज्याने आतील मार्ग वापरला पाहिजे.

दोन अयशस्वीतेचे प्रकार, एक रूट टेबल

आतील क्लायंट आपल्या सर्व्हरकडे UDP सॉकेट उघडतो, आणि ते सॉकेट इतरांसारखेच सध्याच्या रूट टेबलचे अनुसरण करते. जर बाहेरील टनेलकडे आधीच डीफॉल्ट असेल, तर हँडशेक पॅकेट बाहेरील टनेलमध्ये जातात. हे तेव्हाच चालते जेव्हा बाहेरील सर्व्हर आतील सर्व्हरपर्यंत पोहोचू शकतो आणि पलीकडची बाजू फ्लो वाहून नेण्यास संमती देते; अन्यथा हँडशेक थांबतो आणि क्लायंट पुन्हा प्रयत्न करतो.

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

फ्लोला खूण करा आणि त्याला टेबल द्या

निवडलेली रहदारी mangle टेबलमध्ये खूण करून आणि धोरण नियमात ती खूण जुळवून वळवा. नियम डीफॉल्ट रूट आतील उपकरण असलेल्या समर्पित टेबलकडे निर्देश करतो, त्यामुळे फक्त खूण केलेली पॅकेट आतील मार्ग घेतात.

iptables -t mangle -A PREROUTING -p tcp -m multiport --dport 9999 -j MARK --set-mark 0x9999
ip rule add fwmark 0x9999 table 200 pref 1000
ip route add default dev tun1 table 200

या नियम संचातील बहुतेक अयशस्वीता दोन चुकांमुळे येतात. फायरवॉल सेट करणारे खूण मूल्य आणि नियम जुळवणारे मूल्य सारखेच असले पाहिजेत, कारण फरकामुळे त्रुटी किंवा परिणाम मिळत नाही. आणि PREROUTING फक्त बाहेरून येणारी पॅकेट पाहते, म्हणून या होस्टवर सुरू झालेल्या कनेक्शनला खूण होण्यापूर्वी त्याच जुळणीचा OUTPUT नियम लागतो.

दुसऱ्या क्लायंटकडून रूटची मालकी काढून घ्या

दोन पर्याय दुसऱ्या क्लायंटला टेबल संपादित करण्यापासून थांबवतात, आणि ते वेगवेगळ्या टप्प्यांवर काम करतात. route-nopull push केलेल्या रूट पर्यायांकडे दुर्लक्ष करतो, त्यामुळे काहीही स्थापित होत नाही. route-noexec push केलेले पर्याय क्लायंटच्या वातावरणात स्वीकारतो पण टेबल बदल hook वर सोडतो, आणि सर्व्हरने काय देऊ केले हे पाहिजे असताना तुम्हाला हेच हवे असते.

Hook push केलेल्या मूल्यांसह आपल्या वातावरणात चालतो, आणि त्याने फक्त तुम्ही मंजूर केलेल्या नोंदी जोडल्या पाहिजेत. त्याला idempotent करा: पुन्हा बांधण्यापूर्वी त्याच्या मालकीचे टेबल रिकामे करा, आणि मागील फेरीने स्वच्छ स्थिती सोडली असे गृहीत धरू नका. पुन्हा जोडल्यावर hook पुन्हा बोलावला जातो, आणि साफ न करता जोडणारा hook नकली रूट साचवतो.

एक मालक निवडा आणि तो लिहून ठेवा. दोन्ही पर्याय सेट करणारी प्रोफाइल, किंवा हाताने लिहिलेल्या स्क्रिप्टशी स्पर्धा करणारा hook, नंतर कोणीही समजावून सांगू शकत नाही असे टेबल तयार करते.

दोन्ही सर्व्हर पत्ते पिन करा

आतील क्लायंट जोडण्यापूर्वी आतील सर्व्हरला बाहेरील उपकरणातून होस्ट रूट लागतो. तीच नोंद आतील वहन डीफॉल्टचे अनुसरण करू देण्याऐवजी बाहेरील टनेलमध्ये ठेवते.

ip route add 203.0.113.9/32 dev tun0
ip route get 203.0.113.9

मुख्य टेबलमध्ये बाहेरील सर्व्हरसाठीही जुळणारा होस्ट रूट जोडा, अन्यथा पुन्हा जोडल्यावर बाहेरील क्लायंटचे स्वतःचे वहन त्याच्याच टनेलमध्ये राउट होऊ शकते. क्रम ऐच्छिक नाही: संबंधित इंटरफेस अस्तित्वात आल्यानंतर ही नोंदी जोडा, म्हणजे जोडणीनंतर चालणारा hook किंवा स्क्रिप्ट. बंद उपकरणाकडे निर्देश करणारा रूट काढला जातो किंवा दुर्लक्षित केला जातो, त्यामुळे बूटच्या वेळी लिहिलेली नोंद तुम्ही गृहीत धरलेल्या क्रमात टिकत नाही.

संपूर्ण टेबल वाचण्याऐवजी शोध तपासा. रूट शोधाचे आउटपुट kernel वापरणारे उपकरण आणि स्रोत पत्ता सांगते, आणि क्लायंट सॉकेट उघडताना नेमके तेच मिळवतो.

साखळी तपासा आणि अयशस्वीता दिसणारी करा

आतील क्लायंट जोडत असताना बाहेरील इंटरफेसवर कॅप्चर करा. आतील हँडशेक बाहेरील टनेलमध्ये एन्क्रिप्टेड पेलोड म्हणून दिसला पाहिजे; जर तो 203.0.113.9 कडे साधा UDP म्हणून दिसला, तर होस्ट रूट नाही आणि साखळी कधीच बांधली गेली नाही.

भौतिक अपलिंकवर शांतपणे परत जाणारी साखळी हा सर्वात वाईट परिणाम आहे, कारण इंटरफेसची स्थिती काहीही जाहीर करत नाही आणि आतील रहदारी चुकीच्या स्रोत पत्त्यावरून बाहेर पडते. बाहेरील टनेल पडल्यावर दुसरा क्लायंट थेट पुन्हा जोडू शकत असेल, तर तो मार्ग बंद करा किंवा अयशस्वीता दिसावी म्हणून त्याला बाहेरील इंटरफेसला बांधा.

दोन फ्लो आणि एक नियम डंपने संपवा: खूण केलेले आणि न केलेले कनेक्शन वेगळे मार्ग घेतले पाहिजेत, आणि ip rule show ने तुमचा हेतू असलेला प्राधान्य सूचीबद्ध केला पाहिजे. दोन्ही फ्लो एकाच मार्गाने गेल्यास, खूण तुम्ही विचार करता तिथे लागू होत नाही.