गेस्ट VPN र होस्ट VPN: कुन मार्गले साँच्चै जित्छ

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

पहिले गेस्टको जडान अभिलेख गर्नुहोस्

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

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

गेस्टको अन्त्य बिन्दु बाहिरतर्फ पछ्याउनुहोस्

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

कुनै पनि सन्दर्भमा फराकिलो मार्गले अर्को क्लाइन्टले अपेक्षा गरेको ट्राफिक समात्छ। गेस्टभित्रको 0.0.0.0/0 मार्ग र पूर्ण टनेल भएको होस्ट क्लाइन्ट दुवैले सबैमा दाबी गर्छन्, र अन्तमा लागू हुने जित्छ। गेस्टका भर्चुअल नेटवर्क, स्थानीय LAN र टाढाका नेटवर्कबीचको ओभरल्यापले निजी प्रिफिक्सका लागि त्यही प्रभाव पार्छ, असफलता प्रमाणीकरण समस्याजस्ता देखिन्छन्; ठेगाना अनुवादको व्यवहार कन्टेनर नेटवर्किङ का लागि वर्णन गरिएको जस्तै हो।

पहिले र पछिको अभिलेख तुलना गर्नुहोस्

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

ip route get 10.20.30.41
ip rule show
resolvectl status --no-pager | head -12

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

पुनःसुरुवातभरि स्वामित्व स्पष्ट राख्नुहोस्

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

पूर्वनिर्धारित मार्ग कुन पक्षको हो भनेर निर्णय गर्नुहोस् र त्यो सञ्चालन पुस्तिकामा लेख्नुहोस्। गेस्टको पुनःसुरुवात वा होस्टमा नेटवर्क परिवर्तनले स्वामित्व चुपचाप उल्टाउँदा कहिल्यै दोषी नभएको VPN बारे बग रिपोर्ट बन्छ। व्यवस्था रिबुटपछि पनि टिक्नुपर्छ, कसैलाई यो किन चलेको थियो भन्ने सम्झना नहुँदै।