OpenVPN redirect-gateway: प्रत्येक फ्लॅग मार्गांवर काय करतो

प्रोफाइलमध्ये redirect-gateway सह कनेक्ट व्हा, आणि तुमच्या मशीनचा डीफॉल्ट मार्ग नाहीसा होऊ शकतो, दोन भागांत विभागू शकतो, किंवा जिथे होता तिथेच राहू शकतो, हे कोणीही दोन वेळा न वाचणाऱ्या फ्लॅगवर अवलंबून आहे। हा पर्याय फक्त राउटिंगची स्थिती बदलतो आणि दुसरे काहीही नाही, म्हणून त्याने काय केले याचा एकमेव विश्वासार्ह पुरावा म्हणजे क्लायंटने नंतर स्थापित केलेला तक्ता। पुढे येणारे म्हणजे कनेक्शननंतरचा तक्ता, टनेलला स्वतःला जिवंत ठेवणारा मार्ग, आणि हा निर्देश कधीही व्यापतो असे न म्हणणारा IPv6 रहदारी। प्रत्येक पायरी ही अशी आज्ञा आहे जी टनेल सुरू असताना तुम्ही क्लायंटवर चालवू शकता।

प्रत्येक फ्लॅग डीफॉल्ट मार्गावर काय करतो

कोणत्याही फ्लॅगशिवाय, पर्याय सामान्य डीफॉल्ट मार्ग काढून टाकतो आणि त्याच्या जागी टनेल ठेवतो, त्यामुळे कनेक्शन सुरू असताना जुने गेटवे तक्त्यातून नाहीसे होते। def1 जोडा आणि तो डीफॉल्ट यादीत राहतो, दोन अरुंद मार्ग काम करतात। bypass-dhcp जोडा आणि DHCP मार्गही टिकतो, जे अशा नेटवर्कमध्ये महत्त्वाचे आहे जिथे क्लायंटला अजूनही स्थानिक DHCP सर्व्हरपर्यंत पोहोचायचे आहे। OpenVPN 2.6 मॅन्युअल पृष्ठावरील फ्लॅग यादी एकदा वाचण्याइतकी लहान आहे, आणि प्रत्येक नोंद कोणते मार्ग तक्त्यात येतात हे बदलते।

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

def1 तुमच्या डीफॉल्टला न स्पर्शता विशिष्टतेने जिंकतो

दोन अर्ध-डीफॉल्ट मार्ग मिळून IPv4 जागा व्यापतात, 0.0.0.0/1 आणि 128.0.0.0/1। प्रत्येक 0.0.0.0/0 पेक्षा अधिक विशिष्ट आहे, म्हणून शोध त्यांना प्राधान्य देतो, तर खरा डीफॉल्ट सर्वात कमी विशिष्ट जुळणी मागणाऱ्या प्रत्येकासाठी तक्त्यात राहतो।

प्रोफाइल नाही, तक्ता वाचा, कारण तुम्ही यापैकी कोणत्या प्रकरणात आहात हे फक्त तक्ताच दाखवतो। ते वेगळे करण्यासाठी दोन ओळी पुरेशा आहेत:

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

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

टनेलचा शेवटचा बिंदू पोहोचण्यायोग्य ठेवा

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

टनेल सुरू असताना शेवटच्या बिंदूच्या पत्त्यासाठी कोणता इंटरफेस वापरेल असे कर्नेलला विचारा। उत्तरात भौतिक इंटरफेस आणि त्याचे गेटवे असावे, कधीही tun0 नाही:

ip route get 198.51.100.20

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

IPv6 रहदारी स्वतःचाच तक्ता वापरत राहते

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

जोडल्यानंतर v6 तक्ता तपासा, टनेलने तो व्यापला असे गृहीत धरण्याऐवजी। हा निर्देश पत्ता-कुटुंबाचे फ्लॅग याच कारणासाठी बाळगतो, आणि ते वगळणारे प्रोफाइल प्लॅटफॉर्म डीफॉल्टने जे करते ते वारसाहक्काने घेते:

ip -6 route show default
ip -6 route get 2001:db8::10

अॅप्लिकेशन कोणता इंटरफेस वापरते हे सिद्ध करा

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

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

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

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