फायरवॉलवर कोणते VPN पोर्ट उघडावेत: प्रोटोकॉलनुसार
PPTP ला TCP 1723 आणि GRE लागते, L2TP/IPsec ला UDP 500 आणि 4500 तसेच ESP लागते, आणि SSTP, OpenVPN व WireGuard ला प्रत्येकी एक पोर्ट लागतो। काय उघडावे ते येथे आहे।
VPN टनेल फायरवॉल पार करेल की नाही हे दोन वेगळ्या नियमांवर ठरते: क्लायंट ज्या पोर्टवर डायल करतो तो पोर्ट आणि पेलोड वाहून नेणारा प्रोटोकॉल। फक्त पहिला उघडला तर टनेल प्रमाणीकरण करते, पण त्यानंतर कोणताही डेटा हलत नाही। किमान एक TCP पोर्ट आणि GRE PPTP साठी, दोन UDP पोर्ट आणि ESP L2TP/IPsec व IKEv2 साठी, आणि एक पोर्ट SSTP, OpenVPN व WireGuard साठी। दिशा, स्थिती ट्रॅकिंग आणि NAT उर्वरित ठरवतात।
क्लायंट ज्या पोर्टवर डायल करतो तिथून सुरुवात करा
प्रत्येक कुटुंबाला एक प्रवेशबिंदू असतो ज्याच्याशी क्लायंट प्रथम संपर्क साधतो, आणि तुमच्या परवानगी नियमाने तोच प्रवेशबिंदू नावाने नमूद केला पाहिजे। PPTP क्लायंट TCP 1723 शी जोडतात। L2TP/IPsec UDP 500 वर IKE सुरू करते आणि NAT ट्रॅव्हर्सल वापरल्यावर UDP 4500 वर जाते, तर L2TP फ्रेम स्वतः टनेलच्या आत UDP 1701 वर असते। SSTP सत्र TCP 443 वर TLS मध्ये गुंडाळते, IKEv2 UDP 500 व 4500 वर बोलणी करते, OpenVPN डीफॉल्टने UDP 1194 वापरते पण अनेकदा TCP 443 वर हलवले जाते, आणि WireGuard UDP 51820 वर ऐकते।
| Family | Rule to add on the gateway | Typical mistake |
|---|---|---|
| WireGuard | UDP port from ListenPort, for the peer address | Assuming 51820 when the config says otherwise |
| OpenVPN | The configured UDP or TCP port, often 443 | Opening 1194 after the server moved |
| SSTP | TCP 443 limited to the gateway IP | Allowing 443 to any destination |
| IKEv2 | UDP 500 and UDP 4500, plus ESP | Allowing only 500 and losing NAT-T |
| L2TP/IPsec | UDP 500, 4500, ESP, and 1701 inside the tunnel | Exposing 1701 to the internet |
| PPTP | TCP 1723 and IP protocol 47 | Writing a rule for TCP 47 |
ही संख्या स्थिर गुणधर्म नसून डीफॉल्ट मानले पाहिजेत। WireGuard इंटरफेस त्याच्या कॉन्फिगरेशनने जाहीर केलेला कोणताही ऐकण्याचा पोर्ट वापरतो, आणि OpenVPN सर्व्हर प्रशासकाने निवडलेल्या कोणत्याही पोर्टवर बसू शकतो। नियम लिहिण्यापूर्वी सर्व्हर कॉन्फिगरेशन वाचा, कारण 1194 साठी उघडलेला फायरवॉल 443 वर हलवलेल्या सर्व्हरसाठी काहीच करत नाही।
तिसरा स्तंभ म्हणजे बहुतेक बदल तिकिटे जिथे चुकतात ती जागा। नियम आहे, पण तो चुकीच्या गंतव्याकडे, चुकीच्या दिशेकडे किंवा चुकीच्या वाहतुकीकडे निर्देश करतो।
GRE आणि ESP प्रोटोकॉल क्रमांक आहेत, पोर्ट नाहीत
GRE आणि ESP ला पोर्टच नाहीत, त्यामुळे फक्त पोर्ट क्रमांक स्वीकारणारा फायरवॉल फॉर्म ते व्यक्त करू शकत नाही। GRE हा IP प्रोटोकॉल 47 आणि ESP हा IP प्रोटोकॉल 50 आहे, दोन्ही IP हेडरच्या प्रोटोकॉल फील्डने जुळवले जातात। TCP पोर्ट 47 असा लिहिलेला नियम कोणाशीही जुळत नाही, आणि अशा प्रकारे PPTP धोरण बरोबर दिसते आणि तरीही हात मिळवणीनंतर प्रत्येक पॅकेट टाकून देते।
ग्राहक राउटर हे पासथ्रू चेकबॉक्सच्या मागे लपवतात, जे प्रोटोकॉल नियम बसवते आणि GRE साठी प्रवाह नकाशित करण्यासाठी लागणारा NAT सहाय्यकही बसवते। खऱ्या फायरवॉलवर तुम्ही स्वतः प्रोटोकॉल जोडता: PPTP सर्व्हरकडे IP प्रोटोकॉल 47 ला परवानगी द्या, IPsec गेटवेकडे IP प्रोटोकॉल 50 ला परवानगी द्या। जिथे प्लॅटफॉर्म प्रोटोकॉल फील्ड देत नाही तिथे एन्कॅप्स्युलेशन हा मार्ग आहे, म्हणूनच IKEv2 UDP 4500 वर मागे पडू शकते आणि म्हणूनच OpenVPN व WireGuard ला ही अडचण कधीच येत नाही।
क्लायंटला दोष देण्यापूर्वी नियम प्रत्यक्षात कशाशी जुळतो ते तपासा। गेटवेवर शून्यावर राहणारा पॅकेट काउंटर सांगतो की नियम कधीच सक्रिय झाला नाही, आणि क्लायंटच्या बाजूला कितीही वेळा पुनर्स्थापित केले तरी ते बदलत नाही।
दिशा, स्थिती आणि NAT उत्तर बदलतात
बाहेर डायल करणारा क्लायंट आणि आत ऐकणारा गेटवे या वेगळ्या गरजा आहेत, आणि तीच पोर्ट यादी एका दिशेने बरोबर व दुसऱ्या दिशेने चुकीची असू शकते। स्थिती जाणणारा फायरवॉल 500 व 4500 वर UDP प्रवाह मागोवा घेतो आणि दुसऱ्या नियमाशिवाय उत्तरे परत जाऊ देतो। ESP आणि GRE पोर्ट वाहत नाहीत, त्यामुळे NAT उपकरणाला पकडण्यासाठी काहीच नसते आणि सत्र मागोवण्यासाठी त्याला सहाय्यक किंवा एन्कॅप्स्युलेशन लागते।
NAT ट्रॅव्हर्सल हा चुकणारा भाग आहे। IKEv2 UDP 500 वर सुरू होते, NAT उपकरण ओळखते आणि UDP 4500 वर पुढे जाते, त्यामुळे फक्त 500 ला परवानगी देणारे धोरण स्थापन होऊन नंतर शांत होणारे टनेल देते। L2TP/IPsec हीच हालचाल करते। तुमच्या कॅप्चरमध्ये पहिली देवाणघेवाण दिसत असेल पण सतत रहदारी नसेल, तर 500 वर थांबणारा नियम शोधा।
प्रत्येक नियमासोबत दिशा नोंदवा। «UDP 4500 ला परवानगी द्या» हे कुठून कुठे हे सांगेपर्यंत काहीच अर्थ देत नाही, आणि फिरत्या क्लायंटसाठी बरोबर असलेला नियम सामान्यतः साइट-ते-साइट सहकार्यासाठी चुकीचा असतो।
प्रत्येक मार्ग कॅप्चरने तपासा
कॅप्चर क्लायंटवर नाही, गेटवेवर चालवा: क्लायंट फक्त जे आले ते नोंदवतो। हे फिल्टर वरील कुटुंबांना व्यापतात आणि कोणता टप्पा गहाळ आहे ते दाखवतात:
sudo tcpdump -ni any tcp port 1723
sudo tcpdump -ni any udp port 500 or udp port 4500
sudo tcpdump -ni any proto gre
sudo tcpdump -ni any proto 50आउटपुट क्रमाने वाचा। बोलणी दिसते पण पेलोड प्रोटोकॉल दिसत नाही, तेव्हा टाकाऊपणा क्लायंट आणि गेटवेच्या दरम्यान कुठेतरी होतो। दोन्ही दिसतात आणि पृष्ठ तरीही अयशस्वी होते, तेव्हा फायरवॉल यापुढे संशयित नाही; राउटिंग, DNS किंवा क्लायंटला दिलेला पत्ता संच पहा।
tcpdump नसलेल्या यंत्रावर तेच पुरावे इंटरफेस व नियम काउंटरमधून येतात। टनेल इंटरफेसवर बाइट आत येतात पण बाहेर जात नाहीत — हे पहिल्या परवानगी नियमाकडे नव्हे तर परतीच्या मार्गाकडे निर्देश करते।
तुम्ही समर्थन करू शकता असा नियम संच सोडा
TCP 443 वरील SSTP पोर्ट-आधारित कोणत्याही फिल्टरला सामान्य HTTPS पासून वेगळे करता येत नाही, आणि नेटवर्क फक्त वेब रहदारीला परवानगी देत असताना हाच उद्देश असतो। म्हणूनच 443 च्या नियमाने संपूर्ण इंटरनेटऐवजी गेटवेला गंतव्य म्हणून नाव द्यावे। टनेल चालू होताच तात्पुरते कोणत्याही-ते-कोणत्याही नियम हटवा। कोणता नियम जुळला, जिथे असेल तिथे प्रोटोकॉल क्रमांक, आणि दिशा लिहून ठेवा, जेणेकरून पुढील व्यक्ती पुराव्यापासून सुरुवात करेल।
क्लाउड पॉइंट-टू-साइट गेटवे निवड दृश्यमान करतात: डाउनलोड केलेले प्रोफाइल 443 वर SSTP किंवा 500 व 4500 वर IKEv2 वापरते, आणि प्रोफाइलने प्रत्यक्षात निवडलेलेच उघडले पाहिजे। आधुनिक नेटवर्कवर PPTP साठी GRE अपवाद योग्य नाही, कारण मोबाइल ऑपरेटर तुमच्या फायरवॉलकडे दुर्लक्ष करून प्रोटोकॉल 47 अनेकदा टाकून देतात। तिकीट बंद करण्यापूर्वी नियम सर्व्हर कॉन्फिगमधील पोर्टशी जुळतो, प्रोटोकॉल फील्ड कुटुंबाला जिथे लागते तिथे सेट आहे, आणि गंतव्य कोणताही पत्ता नसून गेटवे आहे याची खात्री करा।