VPN जुड़ते ही Vagrant VM गायब हो जाता है: टूटा रूट किसका है

बॉक्स एक मिनट पहले जवाब दे रहा था, VPN जुड़ा, और अब वही पता समय-सीमा पर अटक जाता है। तीन खराबियाँ यह लक्षण पैदा करती हैं, और वे अलग-अलग मशीनों पर रहती हैं। मेज़बान निजी नेटवर्क का रूट खो सकता है, अतिथि की NAT रेंज उस रेंज से टकरा सकती है जिसकी घोषणा अब टनल करती है, या पूरा टनल मेज़बान के हर रूट का स्वामित्व ले सकता है। कोई भी कॉन्फ़िगरेशन बदलने से पहले पता लगाएँ कि कौन-सी हुई, क्योंकि हर सुधार कहीं और रहता है।

रूट देखें, बॉक्स नहीं

जब टनल चालू हो, तब अतिथि के पते के लिए मेज़बान का रूटिंग निर्णय देखें। जो रूट अब भी केवल-मेज़बान एडाप्टर की ओर इशारा करता है, वह समस्या नहीं है। जो रूट अब VPN एडाप्टर की ओर इशारा करता है, वही समस्या है, और उसे क्लाइंट ने बदला, आपने नहीं। एडाप्टर का अपना पता बनाए रखना बताता है कि इंटरफ़ेस बचा रहा, जो रास्ते के बचे रहने से अलग तथ्य है।

जुड़ने के ठीक समय पर गिरने वाला SSH सत्र अपेक्षित व्यवहार है। क्लाइंट एडाप्टर दोबारा इस्तेमाल करता है और रूट डालता है, इसलिए कनेक्शन कुछ सेकंड मर जाता है। खराबी वह कनेक्शन है जो कभी नहीं लौटता, वह नहीं जो पल भर झपका।

टनल से पहले तालिका पकड़ें और बाद में फिर से, फिर उन दोनों आउटपुट की तुलना करें। अंतर ही निदान है, और वही सबूत भी है जो नेटवर्क मालिक माँगेगा।

ip -4 route get 192.168.56.10
ip -brief addr show
ip route show table main | head -20

जुड़ने से पहले और बाद में मेज़बान की तालिका पढ़ें

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

अतिथि प्रीफ़िक्स के रूट के बगल में एडाप्टर और उनके मीट्रिक छापें। आउटपुट की वह जोड़ी स्वामित्व का सवाल एक नज़र में हल कर देती है।

Get-NetAdapter | Select-Object Name, InterfaceIndex, InterfaceMetric
Get-NetRoute -DestinationPrefix 192.168.56.0/24
route print -4 | Select-String '192.168.56'

अगर रूट बदला पर एडाप्टर का मीट्रिक नहीं, तो क्लाइंट ने मुकाबला करने वाला रूट डाला है। अगर मीट्रिक बदला, तो क्लाइंट ने एडाप्टर का क्रम बदला है। दोनों सुधारे जा सकते हैं, और दोनों अलग जगहों पर सुधरते हैं।

जब अतिथि की NAT रेंज ही टकराव हो

VirtualBox NAT डिफ़ॉल्ट रूप से 10.0.2.0/24 इस्तेमाल करता है, और वही रेंज धकेलने वाला टनल अतिथि को वह ट्रैफ़िक असली गंतव्य की बजाय अपने NAT गेटवे पर भेजने पर मजबूर करता है। पैकेट मेज़बान से कभी बाहर नहीं जाता, इसलिए दूसरी तरफ़ का कोई फ़ायरवॉल लॉग उसे नहीं दिखाएगा। Docker Machine में उसके केवल-मेज़बान प्लान में उसी तरह का टकराव है, और उस प्लान को बदलने के लिए मशीन को उसके प्रमाणपत्रों समेत फिर से बनाना पड़ सकता है।

बदलाव चुनने के लिए सूची बनाएँ: टनल पहले से क्या घोषित करता है, फिर ऑफ़िस नेटवर्क क्या इस्तेमाल करता है, फिर इस मेज़बान पर हर वर्चुअल एडाप्टर ने क्या दावा किया है। ओवरलैप ही रूटिंग तोड़ता है, और समानता का कोई मतलब नहीं है। एक रेंज दूसरी के भीतर पूरी तरह बैठ सकती है, जबकि पहली नज़र में वे बिलकुल एक जैसी नहीं दिखतीं।

मशीन बनते समय ही नई रेंज तय करें, या उसे बदलकर फिर से लोड करें, और फिर अतिथि से विफल कनेक्शन फिर जाँचें। अतिथि की अपनी तालिका ही वह दृश्य है जो मायने रखता है।

VBoxManage modifyvm devbox --natnet1 10.77.0.0/24
vagrant reload devbox --provision
vagrant ssh devbox -c 'ip route get 10.20.0.15'

क्लाइंट से लड़े बिना रास्ता बहाल करें

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

बूट पर अंधे पुनःकनेक्शन की बजाय जाँच को स्क्रिप्ट करें। हर कनेक्शन के बाद अतिथि प्रीफ़िक्स का रूट छापने वाली छोटी स्क्रिप्ट रहस्य को लॉग की एक पंक्ति बना देती है।

अगर प्रोफ़ाइल पूरा टनल है, तो नेटवर्क मालिक से स्प्लिट टनलिंग या लिखित अपवाद माँगें। सुरक्षा नीति को बचाने वाले रूट चुपचाप जोड़ना सुधार नहीं है, वह दूसरी समस्या है जो बाद में ऑडिटर के साथ आती है।

सुधार को दोनों तरफ़ जाँचें

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

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

ip -4 route get 192.168.56.10
traceroute -n -m 4 10.20.0.15
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

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