तुमची 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 पर्यंत वाढवू नका.