एक IPv4 गंतव्य OpenVPN बोगद्याबाहेर कसे पाठवायचे

बहुतेक पूर्ण-बोगदा सेटअप प्रत्येक पॅकेट VPN मधून पाठवतात, आणि redirect-gateway ही ते शक्य करणारी सूचना आहे। एकच गंतव्य तरीही वगळता येऊ शकते। त्या पत्त्यासाठी net_gateway प्लेसहोल्डरसह होस्ट मार्ग जोडल्यास क्लायंटला तो मशीनच्या मूळ गेटवेमधून गाठायला सांगितले जाते, तर बाकी सर्व बोगदा वापरत राहते.

ओळ निरुपद्रवी वाटते आणि बहुतेकदा तशी असते, पण ती फक्त एक प्रश्न सोडवते: त्या नेमक्या IPv4 पत्त्यासाठीचे पॅकेट कुठे जातात। ती DNS, IPv6, फायरवॉल धोरण किंवा कोणत्या प्रक्रियेने कनेक्शन उघडले हे बदलत नाही, आणि यापैकी प्रत्येकजण सूट शांतपणे निष्फळ करू शकतो.

net_gateway प्रत्यक्षात काय नाव देतो

त्या सुटीसाठी प्रोफाइल नोंद एकच ओळ आहे: route 198.51.100.77 255.255.255.255 net_gateway। पहिला पत्ता गंतव्यासाठी दस्तऐवजी प्लेसहोल्डर आहे, मास्क त्याला एक-होस्ट मार्ग बनवतो, आणि शेवटचा टोकन गेटवे प्लेसहोल्डरचे नाव देतो। OpenVPN मार्ग स्थापित करताना गेटवे प्लेसहोल्डर सोडवते। vpn_gateway म्हणजे बोगद्याचा स्वतःचा गेटवे, म्हणजे VPN दुव्याची दूरची बाजू। net_gateway म्हणजे VPN ने काहीही बदलण्यापूर्वी होस्टकडे असलेला डीफॉल्ट गेटवे, जो सामान्यतः भौतिक नेटवर्कमधील स्थानिक राउटर असतो.

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

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

होस्ट मार्ग बोगद्याच्या डीफॉल्टवर का जिंकतो

राउटिंग सर्वात विशिष्ट जुळणाऱ्या प्रीफिक्सद्वारे ठरते। redirect-gateway def1 सामान्यतः डीफॉल्ट मार्ग बदलत नाही; तो दोन अर्धे जोडतो, पत्ता जागेच्या खालच्या अर्ध्यासाठी एक मार्ग आणि वरच्या अर्ध्यासाठी दुसरा, जेणेकरून मूळ डीफॉल्ट मार्ग इतर वापरांसाठी राखला जातो। हे अर्धे एका पत्त्यापेक्षा रुंद आहेत.

255.255.255.255 मास्कसह एका पत्त्याचा मार्ग /32 आहे, जो IPv4 ला शक्य असलेली सर्वोच्च विशिष्टता आहे। त्या पत्त्यासाठी पॅकेटचे मूल्यांकन करताना /32 जुळतो आणि कोणता मार्ग आधी स्थापित झाला याची पर्वा न करता जिंकतो। हीच सुटीमागील क्रियाविधी आहे, आणि मार्ग खरोखर अस्तित्वात असल्यास ती Linux, macOS आणि Windows वर सारखीच काम करते.

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

सूट काय झाकत नाही

DNS पहिली त्रेरी आहे। क्लायंट अंतर्गत रिझोल्व्हर सेटिंग्ज ढकलू शकतो, आणि ऑपरेटिंग सिस्टम त्या शोधांसाठी वापरत राहील। कनेक्ट होण्यापूर्वी नाव सोडवणारे अॅप्लिकेशन सरळ जावयाच्या सेवेसाठी अंतर्गत पत्ता, किंवा बरोबर सोडवला गेल्यावरही पुढील त्रेरीत अडखळणारा बाह्य पत्ता मिळवू शकते.

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

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

स्वतःला फसवून न घेता सूट तपासणे

ब्राउझरपासून नव्हे, स्थापित मार्गापासून सुरुवात करा। Linux वर कर्नेलला विचारा की त्या विशिष्ट पत्त्यासाठी कोणता मार्ग आणि पुढील हॉप वापरेल; Windows वर त्या /32 साठी मार्ग सारणी वाचा। गेटवे भौतिक आहे, बोगदा नाही याची खात्री करा। नोंद नसल्यास प्रोफाइल लागू झाले नाही किंवा क्लायंटकडे मार्ग बदलण्याचा अधिकार नव्हता.

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

शेवटी, मार्गावर मात करू शकणारी नियंत्रणे तपासा। क्लायंट-साइड kill switch किंवा Windows ची block-outside-dns सेटिंग थेट रहदारी प्रतिबंधित करू शकते, जे मार्ग बरोबर असूनही अयशस्वी होणारे कनेक्शन म्हणून दिसते। सूट काम करत असल्याचे दाखवण्यासाठी ती नियंत्रणे बंद करू नका; धोरण थेट मार्ग प्रतिबंधित करत असेल, तर सूट VPN सेवेच्या मालकासाठी रचना समस्या आहे.

पुन्हा कनेक्ट किंवा नेटवर्क बदलल्यानंतर पुन्हा तपासा, कारण VPN पूर्वीचा गेटवे आणि उपलब्ध मार्ग प्रोफाइलचे नव्हे, तर क्षणाचे गुणधर्म आहेत.