VPN पता बनाम LAN DHCP लीज़: टनल IP कौन देता है?

क्लाइंट जोड़ें और Wi-Fi आइकन की जगह एडाप्टर देखें। 10.80.0.14 जैसा पता टनल पर हो सकता है, जबकि ऑफ़िस LAN का कोई DHCP सर्वर उस लीज़ को कभी दर्ज नहीं कर चुका हो। किस प्रक्रिया ने नंबर चुना, यह तय करता है कि समस्या-निवारण कहाँ से शुरू होगा।

क्लाइंट पर सब कुछ एक जैसा दिखता है: एक IPv4 पता, एक मास्क, कभी-कभी एक डिफ़ॉल्ट गेटवे। फ़र्क़ तब ही दिखता है जब आप पूछें कि उस पते का जवाब कौन देता है और उसका रिकॉर्ड कौन रखता है।

क्लाइंट की तरफ़ से टनल पता पढ़ें

Windows फ़र्क़ तब दिखाता है जब आप पहली पंक्ति नहीं, पूरा ब्लॉक पढ़ें। ipconfig /all एडाप्टर विवरण, भौतिक पता और एक DHCP पंक्ति छापता है। PPP या IKEv2 डायल-अप एडाप्टर सामान्यतः DHCP को निष्क्रिय बताता है, क्योंकि कनेक्शन ने LAN सर्वर से लीज़ लेने की जगह डायल-अप के दौरान ही अपने पते पर बातचीत की थी। DHCP सक्षम वाला टनल एडाप्टर असामान्य है और उसकी अलग जाँच बनती है।

Linux वही जानकारी दो उपकरणों में बाँटता है। ip -4 addr show dev tun0 पता और प्रीफ़िक्स की लंबाई देता है। nmcli -f IP4 connection show work बताता है कि मान कनेक्शन प्रोफ़ाइल से आया, लिंक पर हुए DHCP आदान-प्रदान से, या थोपे गए कॉन्फ़िगरेशन से। WireGuard सबसे साफ़ मामला है, क्योंकि इंटरफ़ेस दिखते ही wg-quick कॉन्फ़िग फ़ाइल की Address पंक्ति लागू करता है और जुड़ने के समय कोई पीयर कुछ आवंटित नहीं करता।

प्रीफ़िक्स भी कुछ कहता है। /32, या 255.255.255.255 का मास्क, मतलब गेटवे एक ही होस्ट पते तक रूट करने की उम्मीद करता है, जबकि चौड़ा मास्क टनल के पीछे कहीं ऑन-लिंक सबनेट का संकेत देता है।

IKEv2 कॉन्फ़िगरेशन पेलोड क्या ले जाता है

इस काम के लिए IKEv2 का अपना तंत्र है। RFC 7296, अनुच्छेद 3.15.1 में वर्णित कॉन्फ़िगरेशन पेलोड INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS और उनके IPv6 समकक्ष जैसी विशेषताएँ ले जाता है। पसंद न होने पर क्लाइंट शून्य लंबाई के मान वाली विशेषता भेजता है, और उत्तरदाता वह मान लौटाता है जो वह इस्तेमाल करना चाहता है। यह आदान-प्रदान पहले से एन्क्रिप्टेड IKE_AUTH के भीतर चलता है, इसलिए कोई DHCP प्रसारण कभी टनल पार नहीं करता।

इससे दो नतीजे निकलते हैं। पहला, पता उत्तरदाता चुनता है या जिस भी प्राधिकरण बैकएंड से वह परामर्श लेता है, इसीलिए पूल गेटवे पर, RADIUS उत्तर में या पहचान प्रदाता के मैपिंग में रह सकता है। दूसरा, DNS विशेषता पते की विशेषता से अलग है। 10.80.0.14 मिलने से यह कुछ नहीं पता चलता कि कौन सा रिज़ॉल्वर लौटा, या कोई लौटा भी या नहीं।

नेटमास्क विशेषता व्यवहार में वैकल्पिक है। कई परिनियोजन केवल एक पता लौटाते हैं और क्लाइंट को होस्ट रूट लगाने देते हैं, इसीलिए एक ही पूल एक क्लाइंट पर /32 और दूसरे पर /24 जैसा दिख सकता है।

जहाँ LAN DHCP स्कोप और VPN पूल टकराते हैं

मुश्किल तब शुरू होती है जब दोनों आवंटक एक ही रेंज की ओर इशारा करते हैं। 10.20.30.0/24 के लिए DHCP सर्वर 10.20.30.128/25 के लिए बने VPN पूल के बारे में कुछ नहीं जानता, इसलिए गेटवे जब वही पता किसी दूरस्थ क्लाइंट को देता है, तब उसे 10.20.30.140 किसी प्रिंटर को लीज़ पर देने से कोई नहीं रोकता। टकराव कई दिन चुपचाप रहता है और फिर रुक-रुक कर आने वाली डुप्लिकेट के रूप में सामने आता है।

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

टनल को LAN पर ब्रिज करने से वह अलगाव हट जाता है। अगर डिज़ाइन को सचमुच एक ब्रॉडकास्ट डोमेन चाहिए, तो VPN एंडपॉइंट को खुद पते जारी करने की जगह रिले या साझा प्रामाणिक स्रोत के ज़रिये DHCP सर्वर जैसे ही आवंटन निर्णयों में हिस्सा लेना होगा।

जाँचें कि पता किस प्रक्रिया का है

स्कोप बदलने से पहले स्वामित्व साबित करें। क्लाइंट पर पता और प्रीफ़िक्स दर्ज करें। LAN पर लीज़ डेटाबेस में खोजें। गेटवे पर वे पूल गिनाएँ जिन्हें बाँटने के लिए वह कॉन्फ़िगर है। लीज़ फ़ाइल में मिला पता DHCP सर्वर का होता है, यानी टनल ब्रिज्ड या रिलेड है; केवल गेटवे पूल में मिला पता टनल एंडपॉइंट का होता है।

# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0

# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases

# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools

जवाब साफ़ होने पर चार बातें दर्ज करें: कौन-सा घटक क्लाइंट पता आवंटित करता है, उसके लिए कौन-सी रेंज आरक्षित है, वापसी ट्रैफ़िक उस रेंज तक कैसे पहुँचता है, और कौन-से संसाधन उसे स्वीकार करते हैं। ये चार प्रविष्टियाँ वर्चुअल एडाप्टर की एक पंक्ति को परिचालन तथ्य बना देती हैं।

वहीं रहते हुए DNS विशेषता की जाँच दोहराएँ। जो पूल पते देता है पर रिज़ॉल्वर नहीं, वह क्लाइंट को उसके स्थानीय DNS पर छोड़ देता है, जो उस पूल से अलग विफलता है जो LAN के पहले से इस्तेमाल हो रहे पते को बाँटता है।