दोन गेटवे, एक VPN: OpenVPN चुकीचा अपलिंक का निवडतो

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

टनेलचा पत्ता अंतिम टोक नाही

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

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

क्लायंटने प्रत्यक्षात डायल केलेला पत्ता शोधा

कॉन्फिगरेशन फाइलऐवजी जिवंत सॉकेट वाचा। सॉकेट तक्ता प्रक्रियेने प्रत्यक्षात जोडलेला पीअर दाखवतो, आणि अपवादाने त्या मूल्याशी जुळणे आवश्यक आहे। सत्र सुरू झाल्यानंतरही प्रोफाइल संपादित केले जाऊ शकते, आणि कशावर डायल केले याचा एकमेव पुरावा सॉकेट आहे:

ss -tunp | grep -i openvpn
journalctl -u openvpn-client@work --no-pager | grep -i "Peer Connection Initiated"

लॉग ओळ कनेक्शनच्या वेळी पीअरचा पत्ता आणि पोर्ट नोंदवते। ती प्रोफाइलशी जुळत नसेल, तर क्लायंटच्या पुढे काहीतरी कनेक्शन सुरू होण्यापूर्वी गंतव्य पुन्हा लिहित आहे।

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

अंतिम टोक पिन करा आणि धोरणाचा क्रम वाचा

होस्ट राउट कोणत्याही डीफॉल्टपेक्षा अधिक विशिष्ट आहे। म्हणून पीअर पत्त्यासाठीचे /32 ते असलेल्या तक्त्यात जिंकते। नेहमीचा आकार गेटवे आणि उपकरण स्पष्टपणे नामनिर्देशित करतो:

ip route add 203.0.113.40/32 via 192.168.10.1 dev eth0

तो राउट शोध त्या तक्त्यापर्यंत पोहोचल्यासच उपयोगी ठरतो। धोरण नियम क्रमाने मूल्यांकन होतात आणि पहिले जुळणीच ठरवते, म्हणून सर्व काही दुसऱ्या तक्त्याकडे पाठवणारा नियम main मधील तुमचा होस्ट राउट बायपास करतो। राउट अधिकृत मानण्यापूर्वी नियम वाचा:

ip rule show
ip route get 203.0.113.40

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

अंतिम टोक सरकल्यावर

अनेक पत्त्यांवर सोडवला जाणारा होस्टनाव उत्तर बदलताच कायमचे /32 अवैध करतो। अनेक remote ओळींच्या प्रोफाइललाही तीच समस्या आहे, कारण क्लायंट त्यापैकी कोणत्याही एकावर उतरू शकतो। राउट हाताने जोडण्याऐवजी क्लायंटच्याच जीवनचक्र हुकमधून ताजेतवाने करा। नाकारलेला पीअर वाचणारी up स्क्रिप्ट होस्ट राउट स्थापित करते आणि अपवादाला वास्तवाशी सुसंगत ठेवते, आणि जुळणारी down स्क्रिप्ट तो काढून टाकते।

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

आतील धोरण वेगळे ठेवा

बाहेरील मार्ग हलवल्याने नवीन खाजगी सबनेटमध्ये प्रवेश मिळत नाही आणि सर्व्हर टनेलमध्ये कोणती गंतव्ये ढकलतो हेही बदलत नाही। खालच्या स्तराचा राउट तार निवडतो; ढकललेले राउट टनेलमध्ये काय प्रवेश करते ते निवडतात। हे दोन निर्णय वेगळे ठेवणेच विभाजन अंदाजण्यायोग्य करते।

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

निकाल दोन स्वतंत्र निरीक्षणांनी पुष्टी करा: सॉकेटचा स्थानिक पत्ता आणि उपकरण, आणि खाजगी गंतव्य ज्या राउटवर सोडवले जाते। दोन्ही तुमच्या हेतूशी जुळल्यास विभाजन खरे आहे। OpenVPN 2.6 मॅन्युअल remote आणि स्थानिक बाइंडिंग पर्याय व्यापते जे क्लायंट कोणत्या पत्त्यावर डायल करेल हे ठरवतात।