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 विकल्प फालिदिन्छ, जसले पूर्ण टनेल निश्चित रूपमा रोक्छ र तैनाथी अवलम्बित निजी मार्गहरूलाई पनि त्यत्तिकै निश्चित रूपमा तोड्छ, त्यसैले यो एउटा विकल्पमा लक्षित नाम-फिल्टरभन्दा धेरै ठूलो हथौडा हो। कुनै पनि परिवर्तनपछि निजी गन्तव्य, सार्वजनिक गन्तव्य र रिजोल्भर जाँच्नुहोस्, र पूरा भएको ह्यान्डशेकलाई ह्यान्डशेकबाहेक अरू कुनै कुराको प्रमाण नमान्नुहोस्।