VPN पोर्ट खोलने से क्लाइंट LAN तक नहीं पहुँचते

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

दो श्रृंखलाएँ, दो अलग गंतव्य

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

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

श्रोता नियम वास्तव में क्या अनुमति देता है

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

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

क्लाइंट से जाँचें, गेटवे से कभी नहीं

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

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

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

फ़ॉरवर्डिंग को एक नहीं, तीन चीज़ें चाहिए

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

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

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

दस्तावेज़ीकरण में दोनों नियम-समुच्चय अलग रखें

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

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

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