तपाईंको पुरानो पूर्वनिर्धारित मार्ग 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 अलगै हेर्नुहोस्। पुरानो पूर्वनिर्धारित जहाँ छ त्यहीँ राख्नुहोस्।