फ़ायरवॉल पर कौन-से 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 अक्सर गिरा देते हैं। टिकट बंद करने से पहले पुष्टि करें कि नियम सर्वर कॉन्फ़िग के पोर्ट से मेल खाता है, प्रोटोकॉल फ़ील्ड वहाँ सेट है जहाँ परिवार को ज़रूरत है, और गंतव्य कोई भी पता नहीं बल्कि गेटवे है।