तुमचा जुना डीफॉल्ट मार्ग OpenVPN नंतरही जाणूनबुजून टिकतो

तुम्ही टनेल जोडता, ip route चालवता, आणि मूळ डीफॉल्ट गेटवे अजूनही तिथेच आहे। पुढचा विचार असा येतो की क्लायंटने मार्ग ताब्यात घेतला नाही, म्हणून तुम्ही डीफॉल्ट हाताने काढून टाकता आणि कनेक्टिव्हिटी पूर्णपणे गमावता। तो नोंद राहायला हवा होता। redirect-gateway def1 सह OpenVPN सामान्य डीफॉल्ट बदलण्याऐवजी त्यावर राहणारे दोन अधिक विशिष्ट मार्ग बसवते। जुने गेटवे राहते आणि तुम्ही चाचणी करत असलेला रहदारी वाहून नेणे थांबवते।

def1 प्रत्यक्षात काय करते

हे फ्लॅग 0.0.0.0/1 आणि 128.0.0.0/1 जोडते, दोन्ही टनेलकडे। 0.0.0.0/1 पहिला ऑक्टेट 0 ते 127 असलेला प्रत्येक पत्ता समाविष्ट करते, आणि 128.0.0.0/1 128 ते 255 समाविष्ट करते, त्यामुळे प्रत्येक IPv4 गंतव्याकडे जुन्या डीफॉल्टपेक्षा अधिक विशिष्ट जुळणी असते। कोणता मार्ग जिंकेल हे मेट्रिक नाही, प्रीफिक्सची लांबी ठरवते।

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

का /1 आणि /0 नाही

राउटिंग सर्वात लांब जुळणारा प्रीफिक्स निवडते, सर्वात कमी मेट्रिक नाही, म्हणून डीफॉल्टचे मेट्रिक काहीही म्हणो, /1 /0 ला हरवते। दोन्ही अर्धे आहेत कारण एक /1 फक्त अर्धी जागा व्यापते; फक्त 0.0.0.0/1 असताना 128.0.0.0 पासून वरचे सर्व अजूनही जुन्या डीफॉल्टचे अनुसरण करते, ज्यामुळे काही साइट्स चालतात आणि काही चालत नाहीत असे गोंधळात टाकणारे लक्षण उद्भवते।

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

प्रत्यक्ष राउटिंग तक्ता वाचा

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

default via 192.168.50.1 dev wlan0
0.0.0.0/1 via 10.8.0.1 dev tun0
128.0.0.0/1 via 10.8.0.1 dev tun0

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

पॅकेट प्रत्यक्षात कोणता मार्ग घेते ते तपासा

अधिक विशिष्ट मार्ग अजूनही जिंकू शकतात: खाजगी श्रेणी, स्थानिक सबनेट साठीचा मार्ग किंवा VPN सर्व्हरचा स्वतःचा पत्ता /1 पेक्षा लांब आहे। टनेलला त्याच्या सर्व्हरपर्यंत बाहेरील मार्ग लागतो, आणि ते कनेक्शन पुन्हा टनेलमध्ये पाठवल्यास ते लगेच तुटेल। Linux वर तक्ता डोळ्यांनी वाचण्याऐवजी कर्नेलला विचारा: तुम्हाला स्वारस्य असलेल्या गंतव्यासह ip route get निवडलेला मार्ग, इंटरफेस आणि स्रोत छापते। धोरण-आधारित राउटिंग कॉन्फिगर केलेले असल्यास नियमही तपासा, कारण मुख्य तक्ता पाहण्यापूर्वी नियम दुसरा तक्ता निवडू शकतो।

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

def1 काय व्यापत नाही

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

किल स्विच वेगळ्या प्रश्नाचे उत्तर देतो: टनेल पडल्यावर मशीन काय करते। मार्गाची प्राथमिकता टनेल सुरू असताना रहदारी कुठे जाते हे ठरवते; त्यानंतर फायरवॉल काय करते हे ठरवत नाही। कामाचा क्रम: तक्ता वाचा, दोन्ही अर्धे आहेत याची खात्री करा, अयशस्वी गंतव्यासाठी ip route get चालवा, धोरण नियम तपासा, नंतर IPv6 स्वतंत्रपणे पहा। जुना डीफॉल्ट जिथे आहे तिथेच ठेवा।