VPN क्लाइंट सर्वर तक पहुँचते हैं, LAN तक नहीं: कौन-सा समाधान?

क्लाइंट OpenVPN सर्वर के टनल पते को ping करता है और जवाब पाता है, फिर सर्वर के LAN पर एक होस्ट आज़माता है और कुछ नहीं पाता। यह बँटवारा खराबी को काफ़ी सीमित कर देता है: टनल चालू है, फ़ॉरवर्डिंग शायद काम कर रही है, और जवाब ऐसे दरवाज़े से निकलता है जो वापस नहीं ले जाता। तीन समाधान मौजूद हैं, और सही वाला इस पर निर्भर है कि आप क्या नियंत्रित करते हैं और क्या छोड़ने को तैयार हैं। नीचे दिए तीन सवालों के क्रम से जवाब दें और चुनाव स्वाद का मामला नहीं रहेगा।

पहले तय करें कि कौन-सी दिशा टूटी है

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

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

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

अगर LAN का होस्ट पहले से VPN सर्वर की ओर इशारा करता है, तो आपकी समस्या फ़ायरवॉल नियम या MTU सीमा है, वापसी रास्ता गायब नहीं। फ़िल्टर ठीक करने के लिए रूट न जोड़ें।

पहला सवाल: क्या आप दूरस्थ LAN के राउटर को संपादित कर सकते हैं?

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

यह उस दिन चुपचाप विफल हो जाता है जब कोई पूल बदल देता है। मान एक बार लिख लें और तीनों जगहों में से किसी एक में बदलाव को तीनों का बदलाव मानें।

जो NAS या Layer 3 स्विच सेवा होस्ट करता है, उसे भी वही रूट चाहिए, जब तक वह सब कुछ ऐसे राउटर से न भेजे जिसके पास वह हो। उस डिवाइस को जाँचें जो सबनेट समाप्त करता है, सिर्फ़ उसे नहीं जो इंटरनेट की ओर देखता है। छोटे नेटवर्क में अक्सर तीन डिवाइस रूटिंग पर अपनी राय रखते हैं।

दूसरा सवाल: क्या LAN क्लाइंट पते देखना बंद कर सकता है?

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

कीमत एट्रिब्यूशन है: प्रति क्लाइंट पते LAN के लॉग से गायब हो जाते हैं। LAN के होस्ट पर कोई भी अनुमति सूची तब पूल के बजाय सर्वर का नाम लेगी।

अनुवाद तब चुनें जब सहयोग उपलब्ध न हो, न कि तब जब वह महज़ असुविधाजनक हो। यह क्लाइंट को हर भावी जाँच से छिपाता है, उनमें भी जहाँ आपको जानना होता है कि कौन-सा लैपटॉप कनेक्शन खोलता है। यह ऐसे प्रोटोकॉल भी तोड़ सकता है जो पते को पेलोड में डालते हैं, क्योंकि अनुवाद हेडर में रहता है। कोई भी विकल्प अधिक उन्नत नहीं; दोनों स्वामित्व के बारे में अलग सवालों के जवाब देते हैं।

तीसरा सवाल: क्या सर्वर खुद किसी दूसरी टनल का क्लाइंट है?

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

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

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

फिर दोनों दिशाएँ और दोनों आकार जाँचें

बदलाव के बाद क्लाइंट से LAN के होस्ट तक और फिर LAN के होस्ट से क्लाइंट तक ping करें। दूसरी दिशा वही है जिसे लोग छोड़ देते हैं, और वही अधूरे अनुवाद नियम को उजागर करती है। दोनों नतीजे समय-मुद्रा के साथ दर्ज करें ताकि बाद का रिग्रेशन तुलनीय हो।

फिर असली डेटा भेजें, क्योंकि छोटा ping सफल होना जबकि बड़ा स्थानांतरण अटक जाए MTU का लक्षण है। वह खराबी ठीक तब दिखती है जब आप रूट ठीक करने पर खुद को बधाई देते हैं।

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