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 गेस्टला पहिले दाखवते; आणि तीच सहा उत्तरे रीबूटनंतर टिकतात।