फायरवालमा कुन VPN पोर्टहरू खोल्ने: प्रोटोकल अनुसार
PPTP लाई TCP 1723 र GRE चाहिन्छ, L2TP/IPsec लाई UDP 500 र 4500 तथा ESP चाहिन्छ, र SSTP, OpenVPN र WireGuard लाई प्रत्येक एक पोर्ट चाहिन्छ। के खोल्ने भन्ने यहाँ छ।
VPN सुरुङले फायरवाल पार गर्छ कि गर्दैन भन्ने दुई छुट्टै नियमले तय गर्छ: क्लाइन्टले डायल गर्ने पोर्ट र पेलोड बोक्ने प्रोटोकल। पहिलो मात्र खोल्यो भने सुरुङ प्रमाणीकरण हुन्छ, त्यसपछि कुनै डेटा सर्दैन। न्यूनतम PPTP का लागि एउटा TCP पोर्ट र GRE, L2TP/IPsec र IKEv2 का लागि दुई UDP पोर्ट र ESP, र 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 प्रायः फाल्छन्। टिकट बन्द गर्नुअघि नियम सर्भर कन्फिगको पोर्टसँग मिल्छ, प्रोटोकल फिल्ड परिवारलाई चाहिने ठाउँमा सेट छ, र गन्तव्य कुनै ठेगाना होइन गेटवे हो भनी पुष्टि गर्नुहोस्।