राउटर पर VPN या पोर्ट फ़ॉरवर्डिंग: कौन जीतता है?

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

एक पोर्ट, दो दावेदार स्वामी

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

संपादन से पहले दावा लिखें: परिवार, बाहरी पता, परिवहन, पोर्ट और अनूदित लक्ष्य।

स्थानीय जाँच से पहले अनुवाद चलता है

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

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

यही क्रम पूरी कार्यप्रणाली है, और उपकरण इंटरफ़ेस इसे बदले बिना चेकबॉक्स के पीछे छिपाते हैं। पैकेट कौन-सा पथ लेगा, यह अब भी गंतव्य का स्वामी तय करता है।

यदि LAN होस्ट ही इच्छित अंतिम बिंदु है, तो फ़ॉरवर्डिंग सही है और राउटर को उसी पोर्ट पर भी नहीं सुनना चाहिए।

एक मैपिंग रखें और दूसरी हटाएँ

उस पोर्ट और परिवार के लिए NAT प्रविष्टियाँ सूचीबद्ध करें और बचने वाला चुनें:

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

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

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

बाहर से स्वामी की पुष्टि करें

हर परिवार को अलग जाँचें, क्योंकि राउटर पर समाप्त होने वाला IPv6 कनेक्शन उस IPv4 कनेक्शन के बारे में कुछ नहीं कहता जिसे पुराना नियम रीडायरेक्ट करता है। यह देखने के लिए कि कौन-सा अंतिम बिंदु उत्तर देता है, प्राप्त करने वाली सेवा का लॉग पढ़ें, और क्लाइंट के सफलता संदेश को कमज़ोर प्रमाण मानें। सार्थक परीक्षण के लिए नया प्रवाह चाहिए। बाहरी होस्ट से nc -zvu 203.0.113.7 1194 के साथ जाँच भेजें और विजेता का लॉग journalctl -u openvpn@server -n 20 से पढ़ें। राउटर का श्रोता कनेक्शन स्वयं लॉग करता है, जबकि LAN होस्ट उसे अपनी सेवा में लॉग करता है।

कनेक्शन ट्रैकिंग मौजूदा प्रवाहों को उनके मूल मैपिंग पर रखती है, इसलिए स्थापित सत्र उस नियम से अधिक जी सकता है जिसे आपने अभी ठीक किया है।

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