राउटरवरील 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 होस्ट ते स्वतःच्या सेवेत नोंदवतो.

कनेक्शन ट्रॅकिंग विद्यमान प्रवाह त्यांच्या मूळ मॅपिंगवर ठेवते, म्हणून स्थापित सत्र तुम्ही नुकतेच दुरुस्त केलेल्या नियमापेक्षा जास्त काळ टिकू शकते.

इच्छित अंतिम बिंदूने आपल्या नेहमीच्या ओळख तपासण्यांसह उत्तर दिल्यावर, सुरंगाच्या मागील खाजगी संसाधनाची चाचणी करा. बाह्य श्रोत्यापर्यंत पोहोचणे हे फक्त पहिले पाऊल आहे; अंतर्गत राउटिंग आणि अनुप्रयोग अधिकृतता वेगवेगळे परिणाम आहेत.