त्यो 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 लिज मानेर कहिल्यै संलग्न नभएको दायरा खोज्नबाट रोक्छ।