VM में VPN के ज़रिए होस्ट ट्रैफ़िक रूट करना: छह जाँचें

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

कारण से शुरू करें। या तो कॉर्पोरेट क्लाइंट सिर्फ़ गेस्ट के अंदर इंस्टॉल होता है, या नीति उसे वहीं रखती है, और आपको होस्ट से अंदरूनी बिल्ड सर्वर अब भी चाहिए। अगर होस्ट को अपना क्लाइंट रखने की अनुमति है, तो उसके बजाय वही करें: होस्ट पर एक टनल हर बार दो नेटवर्क और एक 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 तरफ़ फ़ॉरवर्ड हुई रिक्वेस्ट और टनल पर अनूदित रिक्वेस्ट दिखाता है। जो रिक्वेस्ट बाहर जाती है, लौटती है और फिर भी होस्ट को ख़ामोश छोड़ देती है, वह वापसी रास्ते की ओर इशारा करती है।

दो विफलताएँ इसमें से ज़्यादातर की व्याख्या करती हैं। या तो गेस्ट की टनल host-only प्रीफ़िक्स के लिए वापसी रूट नहीं रखती क्योंकि NAT नियम गायब है, या होस्ट रूट ऐसे पते की ओर इशारा करता है जो रीबूट के बाद गेस्ट के पास नहीं रहता। पिछले सत्र के नोट्स पर भरोसा करने के बजाय ip -br addr और ip route get से पते दोबारा पढ़ें।

जाँच 6: इसे रीबूट और हाइपरवाइज़र अपग्रेड में टिकाऊ बनाएँ

दोनों आधे टिकाऊ रखें: होस्ट पर netplan या NetworkManager रूट कॉन्फ़िगरेशन, Windows पर route add ... -p, और /etc/sysctl.d/ में net.ipv4.ip_forward=1 के साथ-साथ फ़ायरवॉल नियमों का सेट जो गेस्ट में फिर से लोड होता है। कॉन्फ़िगरेशन सत्यापित होते ही, अगले कॉर्पोरेट क्लाइंट अपडेट आने से पहले गेस्ट का स्नैपशॉट लें।

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

IPv6 को अपना अलग दौर चाहिए। ip6tables नियम, AAAA रिकॉर्ड और होस्ट रूट का दूसरा परिवार IPv4 सेटअप का पालन नहीं करते, और IPv6 से पहुँचने वाली कॉर्पोरेट सेवा तब स्थायी रूप से टूटी दिखेगी जबकि IPv4 काम कर रहा होगा।

पास या फ़ेल, क्रम से: होस्ट गेस्ट के host-only पते को पिंग कर सकता है; गेस्ट टनल की ओर फ़ॉरवर्ड और MASQUERADE करता है; ip route get आंतरिक प्रीफ़िक्स के लिए गेटवे के रूप में गेस्ट लौटाता है; कॉर्पोरेट नाम सीमित रिज़ॉल्वर से रिज़ॉल्व होते हैं; traceroute गेस्ट को पहले दिखाता है; और वही छह जवाब रीबूट में टिके रहते हैं।