route-gateway हे redirect-gateway नाही: प्रत्यक्षात काय बदलते
हा पर्याय फक्त OpenVPN स्थापित करतो त्या मार्गांना पुढील हॉप देतो. तो काढून टाकल्याने ढकललेला पूर्ण बोगदा बंद होत नाही, आणि दुरुस्ती पुनर्निर्देशनात आहे.
तुमचा बोगदा वर येतो, खाजगी सबनेट प्रतिसाद देते, आणि कोणी प्रोफाइलमधून गेटवे ओळ काढून टाकली तरी सामान्य ब्राउझिंग अजूनही VPN मध्ये गायब होते। हेच संयोजन चुकीच्या निर्देशाच्या संपादनाची बोटांची छाप आहे। काढून टाकलेले क्लायंटला तो स्थापित करतो त्या मार्गांसाठी पुढील हॉप देत होते; ट्रॅफिक पकडणे सुरू ठेवलेले दुसऱ्या ठिकाणाहून आले आणि सर्व्हरने ते ढकलले। व्याप्ती आणि पुढील हॉप वेगवेगळी कामे आहेत, आणि त्यातील फक्त एकच सार्वजनिक गंतव्ये बोगदा वापरतात का हे ठरवते।
तुम्ही काढलेली ओळ पुढील हॉप होती, धोरण स्विच नाही
क्लायंट स्थापित करतो त्या प्रत्येक मार्गाला दाखवण्यासाठी गेटवे पत्ता लागतो, आणि मार्ग स्वतः कोणताही पत्ता न सांगता तेव्हा गेटवे निर्देश हा त्या पत्त्याचा स्रोत असतो। तो काढून टाका तर त्या मार्गांना टांगण्याची जागा राहत नाही, म्हणून ते एकतर स्थापित होत नाहीत किंवा कुठेही न नेणाऱ्या वाटेवर पडतात। खाजगी सबनेट हेच अशा मार्गाने वाहून नेलेले होते।
दरम्यान टिकून राहिलेल्या वर्तनाला दुसरा लेखक आहे: ढकललेल्या ब्लॉकमधील पुनर्निर्देशन पर्याय, जो त्याच्या फ्लॅगनुसार सामान्य बाहेर जाणारा रहदारी बोगद्यात हलवतो। गेटवे काढून टाकल्याने तो बंद होत नाही किंवा कमकुवत होत नाही। निकाल दोन्ही स्थितींपैकी सर्वात वाईट आहे, सार्वजनिक रहदारी अजूनही पकडली जाते आणि बोगद्याला न्याय देणारे खाजगी गंतव्य आता पोहोचण्यापलीकडे आहे। म्हणूनच त्याच भावनेने केलेले दुसरे संपादनही काहीच बदलत नाही।
चार लीव्हर, चार वेगवेगळी कामे
या चर्चेत चार निर्देश एकमेकांच्या जागी उद्धृत केले जातात, आणि त्यापैकी फक्त एक व्याप्ती नियंत्रित करतो, म्हणजे कोणती गंतव्ये बोगद्यातून जातात। दुसरा मार्ग वापरतात तो पुढील हॉप ठरवतो, तिसरा एकच प्रीफिक्स स्थापित करतो, आणि चौथा सर्व्हरने ढकललेले सर्व फेकून देतो, तैनातीला लागणाऱ्या खाजगी मार्गांसह। तक्ता त्यांना नावानुसार नव्हे तर प्रशासक काय बदलू इच्छितो त्यानुसार मांडतो, कारण गोंधळ नावांमुळेच होतो। त्यांना चार स्वतंत्र निर्णय माना आणि तुम्हाला खरोखर उलटायचे आहे ते निवडा।
प्रत्यक्षात चारही अनेकदा एकाच ढकललेल्या ब्लॉकमध्ये, ओळीनंतर ओळ येतात, ज्यामुळे ते एकाच सेटिंगचे भाग वाटतात। ते नाहीत, आणि OpenVPN संदर्भ त्यांना वेगवेगळे यंत्रणा म्हणून नोंदवतो तेच कारण आहे। तुम्ही कोणता निर्णय उलटत आहात हे शोधणे हे काम आहे; संपादन एक ओळ आहे।
| What you are trying to change | Directive that decides it | What it leaves alone |
|---|---|---|
| Which destinations use the tunnel | redirect-gateway | Per-prefix routes and resolver choice |
| The next hop a pushed route points at | route-gateway | Coverage of public destinations |
| One reachable prefix | route | Every other destination, default path included |
| All pushed routing and DNS at once | route-nopull | Nothing, which is the problem |
ढकललेली ओळ फिल्टर करा, पुढील हॉप ठेवा
तुम्ही ज्या व्याप्तीला आक्षेप घेता ती ढकललेला पर्याय म्हणून आली तर अरुंद प्रतिसाद म्हणजे तो पर्याय नावाने दुर्लक्षित करून ढकललेल्या ब्लॉकचा उर्वरित भाग अस्पर्शित ठेवणे। फिल्टर म्हणून लिहिले तर तो खालील ओळीसारखा दिसतो, आणि त्याचे स्थान प्रभावित क्लायंटच्या प्रोफाइलमध्ये आहे, सर्व्हर कॉन्फिगरेशनमध्ये नाही।
pull-filter ignore "redirect-gateway"अरुंदपणा हाच मुद्दा आहे। फिल्टर मजकूर प्रीफिक्सची तुलना करतो, म्हणून लहान नमुना पुढील-हॉप निर्देशाशीही जुळतो, जो खाजगी मार्ग अवलंबून असलेली माहिती अगदी तीच सोलून काढतो आणि मूळ चूक नव्या वेशात पुनरावृत्त करतो। फिल्टर फक्त ढकललेल्या पर्यायांवर कार्य करतो, त्यामुळे स्थानिक पातळीवर लिहिलेली किंवा नेटवर्क व्यवस्थापकाने लादलेली समतुल्य ओळ तो कधीही स्पर्श करत नाही। त्यानंतर पुन्हा कनेक्ट व्हा, कारण जिवंत सत्र सर्व्हरने ढकललेल्याचे पुनर्मूल्यांकन करत नाही।
तक्ता नाही, शोध वाचा
प्रोफाइल पुन्हा लोड केल्यावर कर्नेलला विचारा की दोन गंतव्ये प्रत्यक्षात कुठे जातील: एक खाजगी प्रीफिक्सच्या आत आणि एक सार्वजनिक इंटरनेटवर। मुख्य तक्त्याचा संपूर्ण डंप वाचणे कठीण आणि चुकीचे वाचणे सोपे आहे, कारण मार्ग अस्तित्वात असूनही अधिक विशिष्ट जुळणीकडे हरू शकतो। धोरण-आधारित राउटिंगमध्ये नियम, तक्ता आणि स्रोत पत्ताही तपासणीचा भाग आहेत।
ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule showdef1 प्रकार ओळखण्यासारखा आहे, कारण तो जुनी डीफॉल्ट नोंद दृश्यमान ठेवतो तर अर्ध्या-डीफॉल्टची जोडी शोध जिंकते। त्यामुळे आउटपुटमधील 0.0.0.0/0 ओळ स्वतःच काहीच सिद्ध करत नाही। शोध ज्या प्रश्नाचे उत्तर यादी केवळ देत असल्यासारखे वाटते त्या प्रश्नाचे उत्तर देतो।
DNS, IPv6 आणि खाजगी मार्ग अजूनही कार्य करायला हवा
एक IPv4 पुनर्निर्देशन नाकारणे रिझोल्व्हरबद्दल काहीच सांगत नाही, म्हणून ढकललेला DNS पर्याय मार्ग बरोबर दिसत असतानाही प्रश्न बोगद्यात पाठवत राहू शकतो। IPv6 डीफॉल्ट IPv4 तपासणीने कधीही स्पर्श न केलेल्या पत्ता कुटुंबासाठी तेच करू शकतो। दोन्हींना गृहीतकाऐवजी स्पष्ट निर्णय हवा। त्यानंतर खाजगी सेवा अजूनही प्रतिसाद देते याची खात्री करा, कारण खाजगी मार्ग गमावलेला विभाजित बोगदा विभाजित बोगदा नाही, तो तुटलेला आहे।
एक व्यापक साधन इशाऱ्याला पात्र आहे: route-nopull प्रत्येक ढकललेला मार्ग आणि प्रत्येक ढकललेला DNS पर्याय फेकून देतो, जे पूर्ण बोगदा निश्चितपणे थांबवते आणि तैनाती अवलंबून असलेल्या खाजगी मार्गांनाही तितक्याच निश्चितपणे तोडते, म्हणून ते एका पर्यायावर लक्ष्य ठेवलेल्या नाव-फिल्टरपेक्षा खूप मोठे हातोडे आहे। कोणत्याही बदलानंतर खाजगी गंतव्य, सार्वजनिक गंतव्य आणि रिझोल्व्हर तपासा, आणि पूर्ण झालेल्या हस्तांदोलनाला हस्तांदोलनाशिवाय इतर कशाचाही पुरावा मानू नका।