VM भित्रको VPN मार्फत होस्टको ट्राफिक रुट गर्ने: छ जाँच

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

कारणबाट सुरु गर्नुहोस्। या त कर्पोरेट क्लाइन्ट अतिथिभित्र मात्र स्थापना हुन्छ, या नीतिले त्यसलाई त्यहीँ राख्छ, र तपाईंलाई अझै होस्टबाट भित्री build सर्भर चाहिन्छ। होस्टलाई आफ्नै क्लाइन्ट राख्न अनुमति छ भने त्यही गर्नुहोस्: होस्टमा एउटा सुरुङ सधैं दुई सञ्जाल र NAT भन्दा राम्रो हुन्छ।

जाँच 1: होस्टलाई ठेगाना दिन सकिने लिंक चाहिन्छ

होस्टसँग अतिथिको दोस्रो एडाप्टरकै प्रिफिक्समा रहेको इन्टरफेस हुनुपर्छ। VirtualBox मा host-only, VMware Workstation मा host-only वा अनुकूल VMnet, QEMU/KVM मा आन्तरिक ब्रिज वा tap यन्त्र, र Hyper-V मा Internal स्विच सबै योग्य छन्। अतिथि 192.168.56.2, होस्ट 192.168.56.1, प्रिफिक्स 192.168.56.0/24 प्रयोगशालामा प्रयोग गर्ने मेरो बिन्यास हो।

QEMU को प्रयोगकर्ता-मोड सञ्जाल (-netdev user, पूर्वनिर्धारित SLIRP ब्याकइन्ड) र VirtualBox NAT यो जाँचमा पूर्ण रूपमा असफल हुन्छन्। अतिथिका प्याकेट होस्टमा प्रोक्सी प्रक्रियासम्म पुग्छन्, त्यसैले होस्टले अतिथिका ठेगाना बोक्ने यन्त्र कहिल्यै देख्दैन र रुट देखाउन केही हुँदैन। Hyper-V को Default Switch पनि त्यही कथा हो। होस्टबाट ping 192.168.56.2 असफल भए रोक्नुहोस्: पछि थपिएको कुनै रुटले यसलाई सुधार्दैन।

जाँच 2: अतिथिले फर्वार्ड गर्छ र अनुवाद गर्छ

होस्टबाट आउने प्याकेट host-only स्रोत ठेगाना र आन्तरिक गन्तव्यसँग आउँछन्, त्यसैले अतिथिले ती फर्वार्ड गरेर आफ्नै सुरुङ ठेगानापछि लुकाउनुपर्छ। Linux अतिथिमा यसको अर्थ फर्वार्डिङ, FORWARD accept को जोडी, र सुरुङतर्फ source NAT हो:

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
sudo iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t nat -A POSTROUTING -s 192.168.56.0/24 -o tun0 -j MASQUERADE

MASQUERADE नियम नै मानिसले छोड्ने भाग हो। कर्पोरेट राउटरलाई 192.168.56.0/24 छ भन्ने थाहा विरलै हुन्छ; नियमसँग भित्री सर्भरले अतिथिको सुरुङ ठेगाना देख्छन् र त्यसलाई जवाफ दिन्छन्, र जवाफले अतिथिसम्म फर्कने बाटो भेट्छ।

Windows अतिथि अझै असजिलो छ। SYSTEM\CurrentControlSet\Services\Tcpip\Parameters अन्तर्गत IPEnableRouter=1 अनुवाद बिना फर्वार्डिङ खोल्छ, त्यसैले कर्पोरेट रुटिङ पहिले नै तपाईंको host-only प्रिफिक्सतर्फ फर्केर देखाउने ठाउँमा मात्र यो चल्छ। Internet Connection Sharing ले अनुवाद गर्छ, तर साझा एडाप्टरलाई 192.168.137.1 मा पुनः क्रमाङ्कन गर्छ, त्यसैले होस्ट रुट लेख्नुअघि यसले वास्तवमै लिएको ठेगाना पढ्नुहोस्।

जाँच 3: होस्ट रुटले अतिथिको नाम लिन्छ, सुरुङको होइन

होस्टलाई चाहिने प्रिफिक्स मात्र अतिथिबाट पठाउनुहोस्। Linux मा प्रत्येक प्रिफिक्सका लागि एउटा रुट पुग्छ र त्यो सफासँग फर्कन्छ:

sudo ip route add 10.20.0.0/16 via 192.168.56.2
ip route get 10.20.30.40

Windows मा समान route add 10.20.0.0 mask 255.255.0.0 192.168.56.2 हो। परीक्षण गर्दा -p छोड्नुहोस्, ताकि खराब रुट रिबुटमा मर्छ, र बाटो चलेपछि त्यो थप्नुहोस्। होस्टको पूर्वनिर्धारित रुट नहटाउनुहोस्, जबसम्म होस्टका सबै अनुप्रयोगले सुरुङ प्रयोग गर्नुपर्दैन; यदि साँच्चै पूर्ण सुरुङ आवश्यकता हो भने, दुई /1 रुट थप्नुहोस् र हाइपरभाइजर सञ्जालतर्फको सिधा रुट राख्नुहोस्:

sudo ip route add 0.0.0.0/1 via 192.168.56.2
sudo ip route add 128.0.0.0/1 via 192.168.56.2

Windows होस्टमा इन्टरफेस मेट्रिक पनि जाँच्नुहोस्। host-only एडाप्टर बन्द हुँदा थपिएको रुट तालिकामा रहन्छ तर कहिल्यै ट्राफिक बोक्दैन, र कम मेट्रिक भएको दोस्रो एडाप्टरले त्यही प्रिफिक्सको खोज जित्न सक्छ।

जाँच 4: DNS ले रुट पछ्याउँछ, सुरुङको पूर्वनिर्धारित होइन

रुटले प्याकेट सार्छ; कुन नामले प्याकेट बनाउँछ भन्ने रिजोल्भरले निर्णय गर्छ। होस्टको रिजोल्भर बदल्नुको सट्टा कर्पोरेट रिजोल्भरलाई कर्पोरेट जोनमा सीमित गर्नुहोस्, र नयाँ रुट पहिले नै पुग्ने DNS सर्भरतर्फ त्यो देखाउनुहोस्। होस्टमा systemd-resolved छ भने:

resolvectl dns eth1 10.20.0.53
resolvectl domain eth1 '~corp.example.com'

Windows मा नाम रिजोल्युसन नीति तालिकाको प्रविष्टिले त्यही काम गर्छ: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53। अतिथिले host-only ठेगानामा आफ्नै रिजोल्भर चलाउँछ भने त्यसको सट्टा त्यही ठेगाना प्रयोग गर्नुहोस्, तर त्यो loopback मा होइन, 192.168.56.2 मा जवाफ दिन्छ भनी पुष्टि गरेपछि मात्र।

त्यसपछि ढिला पृष्ठका लागि DNS लाई दोष दिनुअघि MTU जाँच्नुहोस्। सुरुङको इन्टरफेस होस्टको 1500 बाइट इन्टरफेसभन्दा सानो छ, त्यसैले DF बिट राखेर पूर्ण आकारका खण्ड पठाउने होस्टले ती अतिथिभित्र कतै गुमाउँछ। चिरपरिचित लक्षण काम गर्ने ping र TLS ह्यान्डसेकपछि अड्किने आन्तरिक वेब एप हो। अतिथिको फर्वार्ड बाटोमा MSS कस्नुहोस्:

sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

जाँच 5: दुवै छेउबाट प्रमाणित गर्नुहोस्

होस्टबाट आन्तरिक ठेगानातर्फ traceroute वा tracert ले पहिलो हपका रूपमा भौतिक गेटवे होइन, 192.168.56.2 देखाउनुपर्छ। अतिथिमा त्यही प्रयास बाहिर जाँदै गरेको हेर्नुहोस्: tcpdump -ni any host 10.20.30.40 ले host-only पक्षमा फर्वार्ड भएको अनुरोध र सुरुङमा अनुवादित अनुरोध देखाउँछ। बाहिर गएर फर्के पनि होस्टलाई मौन छोड्ने अनुरोधले फर्कने बाटोतर्फ संकेत गर्छ।

दुई असफलताले यसको धेरैजसो व्याख्या गर्छन्। या त NAT नियम नभएकाले अतिथिको सुरुङले host-only प्रिफिक्सका लागि फर्कने रुट बोक्दैन, या रिबुटपछि अतिथिसँग नरहने ठेगानातर्फ होस्ट रुट देखाउँछ। अघिल्लो सत्रका टिप्पणीमा भरोसा गर्नुको सट्टा ip -br addr र ip route get ले ठेगाना फेरि पढ्नुहोस्।

जाँच 6: रिबुट र हाइपरभाइजर अपग्रेडमा टिक्ने बनाउनुहोस्

दुवै आधा टिकाउनुहोस्: होस्टमा netplan वा NetworkManager रुट कन्फिगरेसन, Windows मा route add ... -p, र /etc/sysctl.d/ मा net.ipv4.ip_forward=1 सँगै अतिथिमा पुनः लोड हुने फायरवाल नियमसमूह। कन्फिगरेसन प्रमाणित हुनासाथ, अर्को कर्पोरेट क्लाइन्ट अपडेट आउनुअघि अतिथिको snapshot लिनुहोस्।

हाइपरभाइजरले आफ्ना एडाप्टर पुनः बनाउँदा host-only सञ्जाल पुनः क्रमाङ्कित हुन्छन्, जसले 192.168.56.0/24 मा बनेका हरेक रुट र NAT नियमलाई चुपचाप अमान्य बनाउँछ। अपग्रेडपछि पहिला तीन जाँच क्रममा फेरि चलाउनुहोस्; यसले एक मिनेट लिन्छ र होस्टसँग रुट अझै हुँदा अतिथि नयाँ सबनेटमा गएको अवस्था समात्छ।

IPv6 लाई आफ्नै फेरि चाहिन्छ। ip6tables नियम, AAAA रेकर्ड र होस्ट रुटको दोस्रो परिवारले IPv4 सेटअप पछ्याउँदैनन्, र IPv6 बाट पुग्ने कर्पोरेट सेवा IPv4 चल्दा सधैं बिग्रिएको देखिन्छ।

उत्तीर्ण भए पनि नभए पनि, क्रममा: होस्टले अतिथिको host-only ठेगानालाई पिंग गर्न सक्छ; अतिथिले सुरुङतर्फ फर्वार्ड र MASQUERADE गर्छ; ip route get ले आन्तरिक प्रिफिक्सका लागि गेटवे रूपमा अतिथि फर्काउँछ; कर्पोरेट नाम सीमित रिजोल्भरबाट रिजोल्भ हुन्छन्; traceroute ले अतिथिलाई पहिले देखाउँछ; र ती छ जवाफ रिबुटपछि पनि टिक्छन्।