दुई गेटवे, एउटा VPN: OpenVPN किन गलत अपलिंक छान्छ

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

टनेलको ठेगाना अन्तिम बिन्दु होइन

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

प्रोफाइलको remote प्रविष्टिले बाहिरी गन्तव्यको नाम दिन्छ, त्यसैले त्यही ठेगाना पिन गर्नुपर्छ। होस्टनाम फरक तरिकाले समाधान हुँदा वा प्रोफाइलले धेरै remote सूचीबद्ध गर्दा बदलिने मान पनि त्यही हो।

क्लाइन्टले वास्तवमा डायल गरेको ठेगाना खोज्नुहोस्

कन्फिगरेसन फाइलको सट्टा जीवित सकेट पढ्नुहोस्। सकेट तालिकाले प्रक्रियाले वास्तवमा जोडिएको पियर देखाउँछ, र अपवादले त्यो मानसँग मिल्नुपर्छ। सत्र सुरु भएपछि पनि प्रोफाइल सम्पादन गर्न सकिन्छ, र केमा डायल गरियो भन्ने एकमात्र प्रमाण सकेट हो:

ss -tunp | grep -i openvpn
journalctl -u openvpn-client@work --no-pager | grep -i "Peer Connection Initiated"

लग लाइनले जडानको समयमा पियरको ठेगाना र पोर्ट बताउँछ। यो प्रोफाइलसँग नमिले, क्लाइन्टको अगाडि केही कुराले जडान सुरु हुनुअघि गन्तव्य पुनःलेखन गरिरहेको छ।

ठेगाना परिवार पनि जाँच्नुहोस्। दोहोरो स्ट्याक प्रोफाइलले IPv6 मार्फत जोडिन सक्छ जबकि तपाईंको अपवादले IPv4 मात्र समेट्छ, र त्यसपछि ट्राफिकले तपाईंले लेखेको नियमभन्दा फरक नियम पछ्याउँछ। अन्तिम बिन्दुको तर्फबाट जवाफ दिने प्रोक्सीमा पनि यही लागू हुन्छ। दुवै अवस्थामा रुटले केही नगर्दा पनि टनेल काम गर्छ।

अन्तिम बिन्दु पिन गर्नुहोस् र नीतिको क्रम पढ्नुहोस्

होस्ट रुट कुनै पनि पूर्वनिर्धारितभन्दा बढी विशिष्ट हुन्छ। त्यसैले पियर ठेगानाको लागि /32 त्यो राख्ने तालिकामा जित्छ। सामान्य रूपले गेटवे र यन्त्र स्पष्ट रूपमा नाम दिन्छ:

ip route add 203.0.113.40/32 via 192.168.10.1 dev eth0

त्यो रुटले खोज त्यो तालिकासम्म पुगेमा मात्र मद्दत गर्छ। नीति नियम क्रममा मूल्याङ्कन हुन्छन् र पहिलो मिलानले निर्णय गर्छ, त्यसैले सबै कुरा दोस्रो तालिकामा पठाउने नियमले main मा तपाईंको होस्ट रुटलाई बाइपास गर्छ। रुटलाई आधिकारिक मान्नुअघि नियमहरू पढ्नुहोस्:

ip rule show
ip route get 203.0.113.40

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

अन्तिम बिन्दु सर्दा

धेरै ठेगानामा समाधान हुने होस्टनामले जवाफ बदलिने बित्तिकै स्थायी /32 अमान्य गर्छ। धेरै remote लाइन भएको प्रोफाइलमा पनि त्यही समस्या हुन्छ, किनकि क्लाइन्ट तीमध्ये कुनैमा पनि अवतरण गर्न सक्छ। रुट हातले थप्नुको सट्टा क्लाइन्टकै जीवनचक्र हुकबाट ताजा गर्नुहोस्। वार्ता गरिएको पियर पढ्ने up स्क्रिप्टले होस्ट रुट स्थापना गर्छ र अपवादलाई वास्तविकतासँग मिलाइराख्छ, र मिल्ने down स्क्रिप्टले त्यो हटाउँछ।

ताजा गर्ने काम होस्टको बाँकी रुटिङ कन्फिगरेसनजस्तै एउटै ठाउँमा रेकर्ड गर्नुहोस्। अर्को रिबुटसम्म मात्र रहने रुट परीक्षण हो, समाधान होइन।

भित्री नीति अलग राख्नुहोस्

बाहिरी बाटो सार्दा नयाँ निजी सबनेटमा पहुँच मिल्दैन र सर्भरले टनेलमा कुन गन्तव्य धकेल्छ भन्ने पनि बदलिँदैन। तल्लो तहको रुटले तार छान्छ; धकेलिएका रुटले टनेलमा के प्रवेश गर्छ भन्ने छान्छन्। यी दुई निर्णय अलग राख्नुले नै विभाजनलाई अनुमानयोग्य बनाउँछ।

लक्ष्य इन्क्रिप्टेड यातायातलाई मिटर भएको लिंकबाट टाढा राख्नु मात्र हो भने, पूर्वनिर्धारित रुटलाई छुनुहोस् र एउटै होस्ट अपवाद थप्नुहोस्। एउटा VPN जडान सार्न मेसिनभरिको पूर्वनिर्धारित बदल्दा होस्टका हरेक अन्य अनुप्रयोग बिग्रन्छ।

नतिजा दुई स्वतन्त्र अवलोकनले पुष्टि गर्नुहोस्: सकेटको स्थानीय ठेगाना र यन्त्र, र निजी गन्तव्य समाधान हुने रुट। दुवै तपाईंको मनसायसँग मिलेमा विभाजन वास्तविक हो। OpenVPN 2.6 म्यानुअल remote र स्थानीय बाइन्डिङ विकल्प समेट्छ जसले क्लाइन्ट कुन ठेगानामा डायल गर्ने निर्धारण गर्छ।