VPN सेवाका पोर्ट सूचीहरू तुलना पृष्ठहरूबीच तिनीहरू महत्त्वपूर्ण छन् कि छैनन् भन्ने निर्धारण गर्ने विवरणबिना प्रतिलिपि गरिन्छ: जडान कसले सुरु गर्छ। बाहिर जाने TCP 443 लाई अनुमति दिने नियमले अर्को होस्ट तपाईंको मेसिनमा रहेको श्रोतासम्म पुग्न सक्छ कि सक्दैन भन्नेबारे केही भन्दैन। एउटै योजना तुलना गर्नुअघि तीन अलग आवश्यकताहरू लेख्नुहोस्, र तपाईंको कामलाई वास्तवमै कुन चाहिन्छ भनी चिन्ह लगाउनुहोस्। त्यो पाना भएपछि धेरैजसो तुलनाहरू एउटै छोटो प्रश्नमा खुम्चिन्छन्।

कुनै पनि पोर्ट सूची पढ्नुअघि आवश्यकता अलग गर्नुहोस्

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

LineWho starts itWhat can block itQuestion for the provider
Outbound destinationYour applicationEgress filter on the exit nodeIs this protocol and port allowed to that destination?
Inbound publishingA remote peerNo mapping, no public address, short lifetimeWhich protocol, which external port, and how long does the mapping last?
Tunnel transportYour client to the gatewayThe access network drops that protocolDoes the client offer a fallback the local network permits?

बजारीकरणका भनाइहरूले तीन लाइनलाई जानाजानी धमिलो बनाउँछन्। P2P अनुमतिले गन्तव्य नीति वर्णन गर्छ, समर्पित ठेगानाले ठेगाना वर्णन गर्छ, र पोर्टमा कुनै प्रतिबन्ध छैन भन्ने दाबीले सामान्यतया योजनाले तिनीहरूलाई सूचीबद्ध गर्दैन भन्ने बुझाउँछ। यीमध्ये कुनै पनि वाक्यांशले अरूलाई जवाफ दिँदैन।

एउटा ठोस प्रवाह छान्नुहोस् र त्यसलाई वाक्यका रूपमा लेख्नुहोस्: सुरु गर्ने, यातायात, पोर्ट, ठेगाना परिवार, दिशा। टाढाको होस्टमा अपलोड गर्ने रात्री ब्याकअप क्लाइन्ट बाहिर मात्र जान्छ। तपाईंको टेबलमा रहेको साथीहरू जोडिने खेल सर्भर भित्र आउँछ। दुवैलाई एउटै सुरुङबाट चलाउनु भनेको पानालाई दुवै लाइन चाहिन्छ, तिनीहरूबीचको सम्झौता होइन।

बाहिर जाने पहुँच सुरुङमा होइन, गन्तव्य नीतिमा असफल हुन्छ

अनुवाद गर्ने गेटवेबाट बाहिर जाने ट्राफिकले अवस्था सिर्जना गर्छ। आन्तरिक ठेगाना र पोर्टबाट पहिलो प्याकेटले अनुवाद प्रविष्टि बनाउँछ, र जवाफहरू त्यससँग मिल्छन्, जुन RFC 3022 मा वर्णन गरिएको म्यापिङ व्यवहार हो। यही कारणले ब्राउजरको ट्याब सामान्यतया कुनै पोर्ट अनुरोधबिनै काम गर्छ।

दुई कुराले अझै यसलाई तोड्छन्। निकास नोडले दुरुपयोगयोग्य ठान्ने गन्तव्य वा पोर्ट नम्बर फिल्टर गर्न सक्छ, र अनुप्रयोगले निकास नीतिले कहिल्यै नअपेक्षा गरेको पोर्टमा सुनिरहेको हुन सक्छ। भित्र आउने नियमबारे होइन, गन्तव्य जोडीबारे सोध्नुहोस्, र TCP तथा UDP का लागि फरक जवाफ अपेक्षा गर्नुहोस्।

बहस गर्नुअघि नाप्नुहोस्। यी सुरुङपछाडि बस्ने मेसिनमा चलाउनुहोस्, एक पटक सुरुङ बन्द हुँदा र एक पटक खुला हुँदा:

ss -lntup | sort
nc -vz -w 3 203.0.113.10 443
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://example.com

उही आदेश, उही गन्तव्य, सुरुङका दुई अवस्थाले सञ्चालकलाई त्यसमा काम गर्न सकिने अघि-पछिको तुलना दिन्छ। कागजातको ठेगानालाई तपाईंलाई साँच्चै चाहिने होस्टले बदल्नुहोस्; महत्त्वपूर्ण कुरा तुलना दोहोरिनु हो, कुनै संख्या प्रभावशाली देखिनु होइन।

भित्र प्रकाशनका लागि म्यापिङ, ठेगाना र आयु चाहिन्छ

सार्वजनिक पक्षमा कुनै कुरालाई यो कहाँ पुर्‍याउने भन्ने थाहा नभएसम्म बाहिरबाट कुनैले पनि तपाईंको श्रोतासँग जडान सुरु गर्न सक्दैन। सञ्चालकले राखेको स्थिर पोर्ट आरक्षण, क्लाइन्टले UPnP, NAT-PMP वा PCP मार्फत मागेको म्यापिङ, र मार्गनिर्देशित सार्वजनिक ठेगाना — यी तीन फरक उत्पादन हुन्, तीन फरक सीमासहित।

तीमध्ये कुनैबारे पाँच प्रश्न सोध्नुहोस्: कुन प्रोटोकल, कुन बाह्य पोर्ट, बाह्य पोर्ट स्थानीयभन्दा फरक हुन सक्छ कि, कुन ठेगाना परिवार समेट्छ, र पुनः जोडिएपछि म्यापिङ कति टिक्छ। सक्रिय सत्रसँग बाँधिएको आरक्षण त्यो सत्र सकिएपछि हराउँछ, योजनाको पानाले जे भने पनि।

पहिले स्थानीय आधा पुष्टि गर्नुहोस्, किनकि मृत श्रोता र अवरुद्ध भित्र आउने बाटो बाहिरबाट उस्तै देखिन्छन्:

ss -lntup | grep -E ':(8080|51820)\b'
python3 -m http.server 8080 --bind 0.0.0.0
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080

स्थानीय अनुरोधले 200 फर्काउँदा र तपाईंले नियन्त्रण नगर्ने सञ्जालबाट आएको अनुरोध अझै समय सकिएर जान्छ भने, खाडल सार्वजनिक पक्षमा छ। त्यही क्षण अनुप्रयोगलाई नामले वर्णन गर्नुभन्दा सञ्चालकलाई प्रोटोकल र बाह्य पोर्ट भन्नुपर्ने हुन्छ।

सुरुङको आफ्नै यातायात छुट्टै प्रश्न हो

वाहक पोर्टहरू समस्याको सबैभन्दा सानो भाग हुन् र खोज्न सबैभन्दा सजिलो। पूर्वनिर्धारित मानहरू प्रोटोकलअनुसार फरक पर्छन्, र क्लाइन्टले कसमा वार्ता गर्न सक्ने कुरा कुनै पनि योजना वर्णनभन्दा बढी महत्त्वपूर्ण छ।

ClientOuter transportDefault portWhen it helps
OpenVPNUDP1194Default mode; needs outbound UDP to pass
OpenVPNTCP443UDP is dropped and TCP 443 is not
WireGuardUDP51820Short handshake; there is no TCP mode
IKEv2/IPsecUDP500 and 4500Mobile clients; 4500 carries NAT traversal

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

त्यहाँ हुँदा खण्डीकरणको एउटा परीक्षण उचित छ, किनकि जोडिएर पछि ठूला स्थानान्तरणमा अड्किने सुरुङमा सामान्यतया बन्द पोर्ट होइन, गलत MTU हुन्छ:

ping -M do -s 1400 203.0.113.10
ping -M do -s 1372 203.0.113.10

Windows मा त्यही परीक्षण ping -f -l 1400 203.0.113.10 हो। पार हुने सबैभन्दा ठूलो आकारभन्दा तल सुरुङको MTU सेट गर्नुहोस्, त्यसपछि असफल भएको स्थानान्तरण फेरि जाँच्नुहोस्।

योजनाको शुल्क तिर्नुअघि तीन लाइन जाँच्नुहोस्

तीन लाइन एउटै पानामा राख्नुहोस् र प्रत्येक कोठालाई वाचाको सट्टा नापिएको नतिजाले भर्नुहोस्। यी आदेशले त्यो पानाको स्थानीय आधा भाग करिब एक मिनेटमा बनाउँछन्:

ss -lntup | sort
nc -vz -w 3 203.0.113.10 443
python3 -m http.server 8080 --bind 0.0.0.0
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080
ping -M do -s 1400 203.0.113.10

आउटपुटलाई जाँचसूचीका रूपमा पढ्नुहोस्। सुरुङ खुला हुँदा गन्तव्यले जवाफ दिन्छ भने बाहिर जाने काम गर्छ। तपाईंको सञ्जालबाहिरको होस्टले बाह्य पोर्टको श्रोतासम्म पुगेमा मात्र भित्र आउने काम गर्छ। तपाईंको पहुँच सञ्जालले अनुमति दिने प्रोटोकलमा ह्यान्डसेक पूरा भएपछि वाहक काम गर्छ।

दुई बानीले पानालाई इमानदार राख्छन्। प्रत्येक नतिजाको छेउमा मिति र क्लाइन्ट संस्करण लेख्नुहोस्, किनकि प्रदायकका नीति र क्लाइन्टका पूर्वनिर्धारित मान दुवै चल्छन्। त्यसपछि प्रवाहलाई सेवा गर्ने सबैभन्दा साँघुरो म्यापिङ माग्नुहोस्, किनकि सबै खोल्ने अनुरोधले सामान्यतया प्राविधिक जवाफको सट्टा अस्वीकृति वा थप बिक्री पाउँछ।

सम्बन्धित लेखहरू