राउटरमा 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 होस्टले त्यो आफ्नै सेवामा लग गर्छ।

जडान ट्र्याकिङले विद्यमान प्रवाहहरूलाई तिनको मूल म्यापिङमै राख्छ, त्यसैले स्थापित सत्र तपाईंले भर्खरै सुधारेको नियमभन्दा लामो बाँच्न सक्छ।

इच्छित अन्तिम बिन्दुले आफ्ना सामान्य पहिचान जाँचसहित जवाफ दिएपछि, सुरुङपछाडिको निजी स्रोत जाँच्नुहोस्। बाहिरी श्रोतासम्म पुग्नु पहिलो पाइला मात्र हो; आन्तरिक राउटिङ र अनुप्रयोग अनुमति छुट्टै नतिजा हुन्।