तपाईंको VM ले होस्टको VPN प्रयोग गर्छ? गेस्टभित्रबाट परीक्षण गर्नुहोस्

तपाईं होस्टको सार्वजनिक IP जाँच्नुहुन्छ, त्यसले VPN देखाउँछ, र तपाईं VM सुरक्षित छ भनी निष्कर्ष निकाल्नुहुन्छ। त्यो निष्कर्षलाई यो परीक्षणले समर्थन गर्दैन। गेस्टसँग आफ्नै राउटिङ तालिका, आफ्नै रिजोल्भर र आफ्नै इन्टरफेसहरू छन्, र होस्टको निकास ठेगानाले तिनीहरूबारे केही भन्दैन।

परीक्षण गेस्टभित्र चल्नुपर्छ, र यसले के नापियो भनी बताउनुपर्छ।

होस्टको ब्राउजरबाट होइन, गेस्टभित्रबाट सुरु गर्नुहोस्

पहिले हाइपरभाइजरको नेटवर्क मोड रेकर्ड गर्नुहोस्: NAT, bridged, host-only वा macvtap. NAT मोडमा होस्टले गेस्टको ट्राफिक रुट गर्छ, त्यसैले क्लाइन्टले रुट कसरी स्थापना गर्छ भन्नेमा निर्भर गर्दै होस्टको टनेल लागू हुन सक्छ वा नहुन सक्छ। Bridged मोडमा गेस्ट भौतिक LAN मा समकक्ष सहभागी हुन्छ र होस्टको टनेल अप्रासंगिक हुन्छ। यी दुई मोडले एउटै होस्ट कन्फिगरेसनबाट विपरीत उत्तर दिन्छन्।

केही परिवर्तन गर्नुअघि मोड लेख्नुहोस्, किनकि नतिजाको अर्थ के हुन सक्छ भन्ने कुरा त्यहीले निर्धारण गर्छ।

जसको गन्तव्य तपाईंलाई थाहा छ, एउटा अनुरोध गर्नुहोस्

आफूले देखेको स्रोत ठेगाना रिपोर्ट गर्ने सेवामा निर्दोष अनुरोध पठाउनुहोस्। त्यसपछि त्यो गन्तव्यका लागि गेस्टको आफ्नै राउटिङ निर्णय जाँच्नुहोस्: ip route get 203.0.113.5 ले गेस्टले प्रयोग गर्ने इन्टरफेस र गेटवे प्रिन्ट गर्छ।

यदि इन्टरफेस गेस्टको सामान्य NIC हो भने, त्यो ट्राफिक गेस्टभित्रको टनेलबाट जाँदैन।

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

रिजोल्भर छुट्टै जाँच्नुहोस्

परिवर्तित निकास ठेगानाले त्यो होस्टनाम कुन रिजोल्भरले ह्यान्डल गर्यो भनी बताउँदैन। प्लेटफर्मसँग मिल्ने उपकरणले नाम स्पष्ट रूपमा सोध्नुहोस्, र कुन सर्भरले जवाफ दियो नोट गर्नुहोस्। Split DNS भन्नाले रिजोल्भरको प्रश्न र राउटिङको प्रश्नका फरक उत्तर हुन्छन् भन्ने हो।

ती दुई कुनै पनि दिशामा फरक पर्न सक्छन्, र त्यही फरक प्रायः वास्तविक बग हुन्छ।

systemd होस्टमा, resolvectl query ले उत्तरको पछाडिको इन्टरफेस र DNS सर्भर नाम दिन्छ। पुराना कन्फिगरेसनहरूले सर्भर dig को आउटपुटमा देखाउँछन्। जसरी भए पनि, मुख्य कुरा उत्तर आयो कि भन्ने होइन, कुन सर्भरले जवाफ दियो भन्ने हेर्नु हो।

सफलता मात्र होइन, असफलता नीति पनि परीक्षण गर्नुहोस्

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

टनेल खस्दा भौतिक NIC मा फर्कने गेस्टले NAT मोडले अनुमति दिने कुरा ठ्याक्कै गरिरहेको हुन्छ।

मोड र दायरा रेकर्ड गर्नुहोस्

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

यदि IPv4 ले टनेल पछ्यायो भने त्यो भन्नुहोस्। यो दाबीलाई IPv6, अर्को namespace वा अर्को नेटवर्कको अर्को VM सम्म नबढाउनुहोस्।