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 सम्म पुग्यो भने तपाईंले सुरु गरेको बाटो पुनःस्थापित गर्नुभयो। तीमध्ये एउटा मात्र चल्यो भने बाँकी खराबी अर्को मालिकको क्षेत्रमा छ, र फरकले कुन क्षेत्र हो भन्छ।