वह L2TP पता IPCP है, LAN पर DHCP लीज़ नहीं

कनेक्शन ऊपर आता है और एडाप्टर दफ़्तर की रेंज में एक पता दिखाता है, इसलिए स्वाभाविक निष्कर्ष यह है कि VPN ने आपको LAN पता दिया और इस तरह आपको LAN पर रख दिया। इसका कोई भी आधा हिस्सा पूरी तरह सही नहीं है। L2TP एक PPP सत्र ढोता है, और PPP IPCP के साथ अंदरूनी IPv4 पते पर बातचीत करता है। वह पता दो पक्षों के बीच तय किया गया सत्र पैरामीटर है, दफ़्तर के DHCP सर्वर द्वारा दी गई लीज़ नहीं, और उसे रखना आपको दफ़्तर के तार पर पड़ोसी नहीं बनाता।

एक कनेक्शन में दो पते

L2TP कनेक्शन में दो स्वतंत्र बातचीत होती हैं। बाहरी वाली आपके डिवाइस और VPN एंडपॉइंट के बीच उस नेटवर्क पर एक सुरक्षित रास्ता बनाती है जो आपके पास पहले से है। अंदरूनी वाली PPP सत्र है, और वहीं आपके सत्र का पता और दूसरे सिरे का पता तय होता है। इंटरनेट ट्रैफ़िक पूरी तरह एक तीसरे पते के तहत, एंडपॉइंट के सार्वजनिक पते के तहत, बाहर जा सकता है, इसीलिए VPN जाँच पृष्ठ और एडाप्टर का पता शायद ही मेल खाते हैं।

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

IPCP ठीक-ठीक क्या करता है

IPCP, PPP के लिए IPv4 नियंत्रण प्रोटोकॉल है। हर पक्ष Configure-Request संदेश भेजता है जो अपने मनचाहे विकल्पों का वर्णन करते हैं, और पता विकल्प उनमें से एक है। जिस क्लाइंट के पास अभी पता नहीं है वह आमतौर पर 0.0.0.0 के साथ पूछता है, और सर्वर Configure-Nak के साथ जवाब देता है जिसमें वह पता होता है जो वह क्लाइंट से इस्तेमाल कराना चाहता है। फिर क्लाइंट वही पता माँगता है, और सत्र स्थानीय और दूरस्थ पते के साथ ऊपर आता है।

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

ip addr show ppp0
ip route show default
dmesg | grep -i pppd

pppd लॉग की वह पंक्ति जो स्थानीय और दूरस्थ पता बताती है, उस बातचीत का सफल अंत है। सफल प्रमाणीकरण के बगल में उसका न होना क्रेडेंशियल की ओर नहीं, पता चरण की ओर इशारा करता है।

LAN आपको जवाब क्यों नहीं दे सकता

दूर वाले पक्ष की रेंज से आया पता यह अपेक्षा बनाता है कि उस LAN के होस्ट आप तक पहुँच सकते हैं, और अधिकतर नहीं पहुँच सकते जब तक सर्वर आपके सत्र के पते को सुरंग में वापस न भेजे। पूल के अंदर होना आवंटन के बारे में कथन है, टोपोलॉजी के बारे में नहीं। दफ़्तर के फ़ाइल सर्वर के पास आपके सत्र के पते तक कोई रूट नहीं है जब तक VPN सर्वर उसे अग्रेषित न करे, और करे तो भी अनुमति न हो सकती है।

इसी कारण ओवरलैप करती रेंजें अपने दिखने वाले आकार के हिसाब से बेतुकी परेशानी पैदा करती हैं। अगर पूल क्लाइंट की पहले से इस्तेमाल हो रही LAN से ओवरलैप करता है, तो क्लाइंट की रूटिंग तालिका में अब एक ही प्रीफ़िक्स पर दो दावे हैं, और गलत दावा अक्सर ऐसी वजहों से जीत जाता है जिनका सुरंग से कोई संबंध नहीं है।

पहले सत्र जाँचें, फिर रूट

पहले इंटरफ़ेस, फिर रूट, फिर एक अहम गंतव्य जाँचें। हर चरण का अपना विफलता तरीका है, और तीनों को एक साथ जाँचने से ऐसा निष्कर्ष मिलता है जिसे आप बाद में नहीं सँभाल सकेंगे।

curl -sS --max-time 5 https://ifconfig.me
ping -c 3 10.50.30.20
ip route get 10.50.30.20

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

तीनों चरण अलग रखें

प्रमाणीकरण, पता बातचीत और अग्रेषण अलग-अलग तरह से विफल होते हैं, और हर एक का अलग ज़िम्मेदार है। क्रेडेंशियल पहचान की समस्या है, IPCP का खत्म होना सर्वर नीति की समस्या है, और लौटने वाले रूट का न होना नेटवर्क डिज़ाइन की समस्या है। तीनों को “VPN खराब है” बताने से धीमा हल तय है।

दिया गया पता, वह किस पूल से आया और LAN को उस तक पहुँचना है या नहीं, यह लिख लें। यही एक टिप्पणी अगले व्यक्ति को DHCP लीज़ मान लेने और ऐसी रेंज ढूँढ़ने से रोकती है जो कभी शामिल ही नहीं थी।