राउटर का VPN काम करता है, पर LAN क्लाइंट्स के पास इंटरनेट नहीं है

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

विफलता को LAN होस्ट से पढ़ें

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

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

स्थानीय ट्रैफ़िक और फ़ॉरवर्ड ट्रैफ़िक अलग हैं

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

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

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

वापसी मार्ग भी मौजूद होना चाहिए

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

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

क्लाइंट DNS उसी समीक्षा का हिस्सा है। राउटर का रिज़ॉल्वर जवाब दे सकता है जबकि किसी और सर्वर की ओर इशारा करता क्लाइंट कुछ भी नहीं पाता।

एक अनुमत और एक अस्वीकृत प्रवाह जाँचें

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

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

दूर के छोर पर देखा गया स्रोत पता जाँचें, क्योंकि वह बताता है कि असल में कौन-सा डिज़ाइन चल रहा है। पते के साथ-साथ नाम की पूछताछ भी जाँचें, क्योंकि रिज़ॉल्वर का व्यवहार एक ही बॉक्स से गुज़रने वाला अलग मार्ग है।

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