OpenVPN redirect-gateway: प्रत्येक फ्ल्यागले रुटहरूमा के गर्छ

प्रोफाइलमा redirect-gateway सहित जडान गर्नुहोस्, र तपाईंको मेसिनको पूर्वनिर्धारित रुट हराउन सक्छ, दुई भागमा बाँडिन सक्छ, वा ठ्याक्कै जहाँ थियो त्यहीँ रहन सक्छ, यो कसैले दुई पटक नपढ्ने फ्ल्यागहरूमा भर पर्छ। यो विकल्पले रुटिङको अवस्था मात्र बदल्छ र अरू केही होइन, त्यसैले यसले के गर्यो भन्ने एक मात्र भरपर्दो प्रमाण त्यो तालिका हो जो क्लाइन्टले पछि स्थापित गर्यो। अब आउने कुरा जडानपछिको तालिका, टनेललाई नै जीवित राख्ने रुट, र यो निर्देशनले कहिल्यै ढाक्छ भनी नभन्ने IPv6 ट्राफिक हो। हरेक चरण एउटा आदेश हो जो टनेल खुला रहँदा तपाईंले क्लाइन्टमा चलाउन सक्नुहुन्छ।

प्रत्येक फ्ल्यागले पूर्वनिर्धारित रुटमा के गर्छ

कुनै फ्ल्याग बिना, विकल्पले साधारण पूर्वनिर्धारित रुट हटाउँछ र त्यसको ठाउँमा टनेल राख्छ, त्यसैले जडान खुला रहँदा पुरानो गेटवे तालिकाबाट हराउँछ। def1 थप्नुहोस् र त्यो पूर्वनिर्धारित सूचीमा रहन्छ, दुई साँघुरा रुटले काम गर्छन्। bypass-dhcp थप्नुहोस् र DHCP रुट पनि टिक्छ, जो त्यस्तो सञ्जालमा महत्त्वपूर्ण छ जहाँ क्लाइन्टले अझै स्थानीय DHCP सर्भरमा पुग्नुपर्छ। OpenVPN 2.6 म्यानुअल पृष्ठको फ्ल्याग सूची एक पटक पढ्नलाई छोटो छ, र हरेक प्रविष्टिले कुन रुटहरू तालिकामा पुग्ने भन्ने बदल्छ।

धकेलिएको विकल्प आएपछि उही तरिकाले व्यवहार गर्छ, त्यसैले क्लाइन्ट प्रोफाइलमा केही पनि नहुन सक्छ जबकि तालिका पूर्ण रूपमा पुनर्निर्देशित देखिन्छ। यो सामान्य हो: सर्भरले फ्ल्यागहरू पठायो, क्लाइन्टले तिनीहरू लागू गर्यो, र स्थानीय फाइलले निर्देशनको कहिल्यै उल्लेख गरेन। जब धकेलाइले केही नगरेको जस्तो देखिन्छ, तानिएका विकल्पहरू स्वीकार्ने वा छोड्ने क्लाइन्ट-पक्षीय फिल्टर जाँच्नुहोस्, किनकि छोडिएको विकल्पले कुनै पनि पक्षमा त्रुटि दिँदैन।

def1 ले तपाईंको पूर्वनिर्धारित नछोई विशिष्टताले जित्छ

दुई आधा-पूर्वनिर्धारित रुटहरू मिलेर IPv4 स्थान ढाक्छन्, 0.0.0.0/1 र 128.0.0.0/1। प्रत्येक 0.0.0.0/0 भन्दा बढी विशिष्ट छ, त्यसैले खोजले तिनीहरूलाई प्राथमिकता दिन्छ जबकि साँचो पूर्वनिर्धारित सबैभन्दा कम विशिष्ट मिल खोज्ने जुनसुकैका लागि तालिकामा रहन्छ।

प्रोफाइल नभई तालिका पढ्नुहोस्, किनकि तपाईं तीमध्ये कुन अवस्थामा छौ भन्ने तालिकाले मात्र देखाउँछ। तिनीहरूलाई छुट्याउन दुई लाइन पर्याप्त छन्:

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

हरेक लाइनमा इन्टरफेस र मेट्रिकमा ध्यान दिनुहोस्, गन्तव्यमा मात्र होइन। टनेलतर्फ देखाउने पूर्वनिर्धारित र टनेलतर्फ देखाउने आधा-पूर्वनिर्धारितहरूको जोडीले एउटै मनसाय वर्णन गर्छन् र टनेल खस्दा फरक तरिकाले असफल हुन्छन्, किनकि एउटा अवस्थामा वैकल्पिक बाटो अझै छ। दुवै फाँट परिवर्तन टिप्पणीमा लेख्नुहोस्। बाँचेको वैकल्पिक बाटोले कहिलेकाहीँ टनेल मर्मत गर्न टाढाको सत्रलाई पर्याप्त लामो जीवित राख्छ, र मनसाय पूरा टनेल हुँदा ट्राफिक चुहाउने पनि त्यही हो।

टनेलको अन्तिम बिन्दु पुग्नयोग्य राख्नुहोस्

क्लाइन्टलाई टनेलको टाढाको छेउसम्म पुग्ने यस्तो रुट चाहिन्छ जो आफैँ टनेलबाट जाँदैन। OpenVPN अरू केही बदल्नु अघि त्यो होस्ट रुट स्थापित गर्छ, र हातले रुट सम्पादन वा दोस्रो VPN क्लाइन्टले त्यो हटाउन सक्छ। त्यसपछिको लक्षण जोडिएको छ भनी बताउने र त्यसपछि केही पनि नपठाउने जडान हो।

टनेल खुला रहँदा कर्नेललाई सोध्नुहोस् यसले अन्तिम बिन्दुको ठेगानाका लागि कुन इन्टरफेस प्रयोग गर्छ। जवाफले भौतिक इन्टरफेस र त्यसको गेटवे उल्लेख गर्नुपर्छ, कहिल्यै tun0 होइन:

ip route get 198.51.100.20

यदि त्यो खोजले टनेल यन्त्र फर्काउँछ भने, टनेलले आफ्नै यातायात बोकेको छ र कुनै प्याकेट बाहिर जानुपर्ने बित्तिकै भत्किन्छ। स्थानीय प्रिफिक्स, दोस्रो एडाप्टर र नीति-आधारित रुटिङ यहाँ अझै महत्त्वपूर्ण छन्, त्यसैले सफा ल्यापटपमा काम गर्ने पुनर्निर्देशन व्यवस्थापन इन्टरफेस र दुई पूर्वनिर्धारित भएको होस्टमा असफल हुन सक्छ। सामान्यतया प्रोफाइललाई दोष दिइन्छ, तर काम ठेगाना योजनाले गरेको हुन्छ।

IPv6 ट्राफिकले आफ्नै तालिका प्रयोग गरिरहन्छ

IPv4 पुनर्निर्देशन गर्दा IPv6 लाई छुँदैन, र दुई परिवार फरक फ्ल्यागले बदलिन्छन्। काम गर्ने v6 पूर्वनिर्धारित भएको दोहोरो स्ट्याक होस्टमा v4 ट्राफिक पूरै टनेलभित्र बस्न सक्छ, जबकि v6 सक्षम हरेक गन्तव्य भौतिक लिङ्कबाट बाहिर जान्छ। एउटा तालिकामा ठीक देखिने होस्ट अर्कोमा चुहिन्छ।

जडानपछि v6 तालिका जाँच्नुहोस्, टनेलले ढाक्यो भनी ठान्नुको सट्टा। यो निर्देशनले ठेगाना-परिवारका फ्ल्याग ठ्याक्कै यही कारणले बोक्छ, र ती छोड्ने प्रोफाइलले प्लेटफर्मले पूर्वनिर्धारित रूपमा गर्ने कुरा पाउँछ:

ip -6 route show default
ip -6 route get 2001:db8::10

कुनै एप्लिकेसनले कुन इन्टरफेस प्रयोग गर्छ भनी प्रमाणित गर्नुहोस्

जोडिएको अवस्था अवरोध होइन, र रुट परिवर्तन किल स्विच होइन। यदि टनेल असफल हुँदा सिधा ट्राफिक रोकिनुपर्छ भने, त्यो नीति फायरवालमा बस्छ र त्यसलाई आफ्नै परीक्षण चाहिन्छ।

प्रोफाइलले वर्णन गर्ने बाटो नभई एप्लिकेसनले साँच्चै हिँड्ने बाटो परीक्षण गर्नुहोस्। पहिले रुट सोध्नुहोस्, त्यसपछि पालैपालो हरेक इन्टरफेसमा अनुरोध बाँध्नुहोस् र टाढाको पक्षले के रिपोर्ट गर्छ तुलना गर्नुहोस्:

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

यदि दुवै अनुरोधले एउटै ठेगाना फर्काउँछन् भने, रुटिङ तालिकाले गर्नुपर्ने भने पनि एप्लिकेसनले टनेल प्रयोग गर्दैन। यदि टनेलसँग बाँधिएको अनुरोध मात्र सफल हुन्छ भने, त्यो गन्तव्यका लागि भौतिक बाटो फिल्टर भएको छ र टनेलले तपाईंले खोजेको काम गर्छ। फ्ल्याग, स्थापित रुट, अन्तिम बिन्दुको खोज र दुवै निकास परिणाम परिवर्तन रेकर्डमा लेख्नुहोस्, ताकि अर्को व्यक्तिले स्क्रिनसट नभई तथ्य पाओस्।