क्या आपका VM होस्ट का VPN इस्तेमाल करता है? मेहमान के अंदर से जाँचें

आप होस्ट का सार्वजनिक IP जाँचते हैं, वह VPN दिखाता है, और आप निष्कर्ष निकालते हैं कि VM ढक गया है। इस निष्कर्ष को जाँच का समर्थन नहीं है। मेहमान की अपनी रूटिंग तालिका, अपना रिज़ॉल्वर और अपने इंटरफ़ेस हैं, और होस्ट का एग्ज़िट पता उनके बारे में कुछ नहीं बताता।

जाँच मेहमान के अंदर चलनी चाहिए, और उसे बताना चाहिए कि उसने क्या मापा।

मेहमान के अंदर शुरू करें, होस्ट के ब्राउज़र में नहीं

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

कुछ भी बदलने से पहले मोड लिख लें, क्योंकि यह तय करता है कि परिणाम का क्या अर्थ हो सकता है।

एक अनुरोध भेजें जिसका गंतव्य आप जानते हैं

ऐसी सेवा को हानिरहित अनुरोध भेजें जो उसने देखा स्रोत पता बताती है। फिर उस गंतव्य के लिए मेहमान के अपने रूटिंग निर्णय की जाँच करें: ip route get 203.0.113.5 वह इंटरफ़ेस और गेटवे छापता है जो मेहमान इस्तेमाल करेगा।

अगर इंटरफ़ेस मेहमान का सामान्य NIC है, तो ट्रैफ़िक मेहमान के अंदर की सुरंग से नहीं जाता।

दूसरा एडाप्टर, प्रॉक्सी सेटिंग या मेहमान की ओर का VPN क्लाइंट एक एप्लिकेशन के लिए जवाब बदल सकते हैं और दूसरे के लिए नहीं। उस एप्लिकेशन की जाँच करें जिसकी आपको सचमुच परवाह है, शेल से किया गया सामान्य अनुरोध नहीं।

रिज़ॉल्वर को अलग से जाँचें

बदला हुआ एग्ज़िट पता यह नहीं बताता कि किस रिज़ॉल्वर ने होस्टनाम संभाला। प्लेटफ़ॉर्म से मेल खाने वाले टूल से नाम स्पष्ट रूप से पूछें, और दर्ज करें कि किस सर्वर ने जवाब दिया। विभाजित DNS का मतलब है कि रिज़ॉल्वर प्रश्न और रूटिंग प्रश्न के जवाब अलग हैं।

ये दोनों किसी भी दिशा में अलग हो सकते हैं, और यह अंतर अक्सर असली बग होता है।

systemd होस्ट पर, resolvectl query जवाब के पीछे का इंटरफ़ेस और DNS सर्वर बताता है। पुराने सेटअप सर्वर को dig के आउटपुट में दिखाते हैं — किसी भी तरह, मुद्दा यह देखना है कि किस सर्वर ने जवाब दिया, सिर्फ़ यह नहीं कि जवाब आया या नहीं।

विफलता नीति की जाँच करें, सिर्फ़ सफलता की नहीं

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

जो मेहमान सुरंग गिरने पर भौतिक NIC पर लौट जाता है, वह ठीक वही कर रहा है जिसकी NAT मोड अनुमति देता है।

मोड और दायरा दर्ज करें

हाइपरवाइज़र मोड, मेहमान का इंटरफ़ेस और रूट, रिज़ॉल्वर और आपने जो एप्लिकेशन जाँचा, वह लिखें। तारीख जोड़ें, क्योंकि स्नैपशॉट बहाली या हाइपरवाइज़र अपडेट चारों बदल सकते हैं।

अगर IPv4 ने सुरंग का पालन किया, तो यह कहें। दावे को IPv6, किसी दूसरे नामस्थान या किसी दूसरे नेटवर्क के दूसरे VM तक न बढ़ाएँ।