के TCP 443 ले साँच्चै मद्दत गर्छ? सर्भरले त्यहाँ सुनेको खण्डमा मात्र
TCP प्रोफाइल वैकल्पिक बाटो हो, भेष होइन। सर्भर त्यो पोर्टमा सुन्छ कि जाँच गर्नुहोस्, त्यसपछि दोब्बर TCP को लागतलाई पहुँच नहुने अवस्थासँग तुलना गर्नुहोस्।
TCP 443 पूर्वसर्त भएको वैकल्पिक बाटो हो, कुनै पनि फिल्टरबाट सुरुङ छिराउने भेष होइन। जब अपरेटरले पहिले नै त्यो पोर्टमा TCP श्रोता प्रकाशित गर्छ र बाटोले घण्टौं खुला रहने जडान सहन्छ, तब यसले मद्दत गर्छ। यीमध्ये एउटा पनि नभएमा यो सामान्यतया समय-समाप्तिका रूपमा असफल हुन्छ, र समय-समाप्तिले कुन चाहिँ छुट्यो भन्ने विरलै बताउँछ। परिवर्तन गर्ने कि नगर्ने निर्णयका लागि तीन प्रश्न चाहिन्छ, र तीमध्ये एउटा मात्र पोर्ट नम्बरबारे छ।
पोर्ट नम्बर ढुवानीको वाचा होइन
पोर्टले एउटा अन्त्य बिन्दुको नाम दिन्छ; TCP ले यसलाई क्रमबद्ध बाइट प्रवाहमा बदल्छ; OpenVPN ले त्यो प्रवाहभित्र के यात्रा गर्छ भनेर तय गर्छ। सोही नम्बरको वेब सर्भरले पूर्ण रूपमा फरक अनुप्रयोग व्यवस्था प्रयोग गर्छ, त्यसैले 443 पोर्ट साझा गर्दा फिल्टरका लागि दुवै समान देखिन्छन्, त्यसभन्दा बढी केही होइन। नम्बर फिल्टरले पढ्ने सङ्केत हो, प्याकेटभित्रको सामग्री बदल्ने गुण होइन। पोर्ट साझा गर्छन् भन्दै दुवैलाई एउटै मान्नु यहाँको अधिकांश अन्योलपछाडिको गल्ती हो।
बीचका यन्त्रहरूले पोर्टबारे सरल अनुमति-वा-अस्वीकृति निर्णय विरलै गर्छन्। धेरैले पहिलो बाइट जाँच्छन्, केहीले गन्तव्य स्थिर गर्छन्, र केहीले धेरै बेर खुला रहने जडान रिसेट गर्छन्। त्यसैले एउटै प्रोफाइल एउटा नेटवर्कबाट चल्न सक्छ र अर्कोबाट समय-समाप्तिमा पुग्न सक्छ, र त्यसैले वैकल्पिक बाटोलाई वाचाका रूपमा विश्वास गर्नुभन्दा समर्थित विकल्पका रूपमा परीक्षण गर्नु उपयुक्त हुन्छ। फिल्टरले ट्राफिक जाँच्दा पोर्ट नम्बर उसले हेर्ने पहिलो कुरा मात्र हो।
प्रोफाइल छुनुअघि श्रोता पुष्टि गर्नुहोस्
सर्भर पोर्टमा TCP का लागि कन्फिगर हुनुपर्छ, र क्लाइन्ट प्रोफाइलले त्यही ढुवानी माग्नुपर्छ। UDP प्रोफाइल TCP माग्नका लागि पुनःलेख्दा श्रोता बन्दैन, र त्यसबाट आउने समय-समाप्ति पोर्ट खसाल्ने फायरवालबाट छुट्याउन सकिँदैन। अपरेटरको आफ्नै TCP प्रोफाइल भए त्यो डाउनलोड गर्नुहोस्, किनकि केही सेवाहरूले प्रत्येक ढुवानीका लागि छुट्टै अन्त्य बिन्दु र छुट्टै पहिचान सेटिङ प्रकाशित गर्छन्। हातले सम्पादन नियन्त्रित परीक्षणका लागि ठीक छ र प्रदायकको अभिप्रेत कन्फिगरेसन अनुमान गर्ने नराम्रो तरिका हो।
त्यो मिलनका दुवै पक्ष कन्फिगरेसनमा देखिन्छन्, र OpenVPN परियोजनाका लिङ्क विकल्पहरू ले दुवै रूप अभिलेख गर्छन्। न्यूनतम जोडी यस्तो देखिन्छ:
# server: accept TCP on this port
proto tcp-server
port 443
# client: request the same transport
proto tcp
remote vpn.example.com 443तीन सर्तले वैकल्पिक बाटो लाभदायक छ कि छैन तय गर्छन्
पहिलो सर्त अपरेटरले त्यो ढुवानी नै दिन्छ; त्यो नभए अरू केही महत्त्वपूर्ण हुँदैन। दोस्रो सर्त बाटोले दीर्घकालीन सत्र जीवित राख्छ, किनकि केही नेटवर्कले पोर्ट पूर्ण रूपमा अवरुद्ध गर्नुभन्दा खुला रहने जडान रिसेट गर्छन्। तेस्रो सर्त वैकल्पिक बाटो जानाजान गरिएको अपवाद हो कि तपाईंले नसुधारेको खराबी लुकाउने अस्थायी उपाय हो।
प्रत्येक सर्तको सस्तो जाँच छ। तीमध्ये कुनै एकमा असफलता क्लाइन्टको तर्फबाट उस्तै देखिन्छ:
| Condition | How to check it | What a failure decides |
|---|---|---|
| The server offers TCP | The operator's profile list, or a listening-socket check on the server | No client-side edit can help |
| The path keeps long sessions | A test connection left open for an hour | Reconnects will look like server faults |
| The fallback is deliberate | A change record naming the UDP fault | The underlying fault stays invisible |
ढुवानीहरू तुलना गर्नुअघि क्याप्टिभ पोर्टलमा कुनै पनि साइन-इन पूरा गर्नुहोस्। तपाईंको यन्त्र स्वीकार नगरेको नेटवर्कले दुवै ढुवानी अवरुद्ध गर्छ, र तब तुलनाले सुरुङ होइन, पोर्टल नाप्छ। साइन इन गर्नुहोस्, सामान्य ब्राउजिङ चल्छ भनी पुष्टि गर्नुहोस्, र त्यसपछि मात्र परीक्षण सुरु गर्नुहोस्।
तपाईंले स्वीकार्ने लागत: TCP भित्र TCP
TCP ले हराएका खण्ड पुनः पठाउँछ र तिनको क्रम कायम राख्छ। जब आफैं TCP प्रयोग गर्ने अनुप्रयोग TCP सुरुङभित्र चल्छ, दुई पुनर्प्राप्ति तहले एउटै हानिमा प्रतिक्रिया दिन्छन्, र यही अन्तरक्रियाले सुरुङलाई हानि भएको बाटोमा ढिलो महसुस गराउँछ। लक्षण सफा असफलता होइन, ढिलाइ र कम्पन हो, जसले टाढाको छेउलाई दोष दिन सजिलो बनाउँछ। निष्कर्ष निकाल्नुअघि क्लाइन्टबाट दुवै ढुवानीमा नाप्नुहोस्।
UDP ले यो नेस्टिङबाट बच्छ, र यही मुख्य कारणले अपरेटरहरूले यसलाई रुचाउँछन् र TCP लाई मात्र विकल्पका रूपमा दिन्छन्। स्थिर TCP जडान अझै पहुँच नहुने UDP जडानभन्दा उपयोगी छ, त्यसैले तुलना राम्रो र नराम्रो विकल्पबीच होइन, दुई वास्तविक लागतबीच हुन्छ। तुलना गर्दा यन्त्र र पहुँच नेटवर्क अपरिवर्तित राख्नुहोस्, नत्र परिणामले गलत चर वर्णन गर्नेछ।
केही क्लाइन्ट सुविधाहरू एउटै ढुवानीका लागि मात्र अभिलेखित छन्, त्यसैले वैकल्पिक प्रोफाइलले तपाईंले भरोसा गरेको व्यवहार चुपचाप छोड्न सक्छ। TCP प्रोफाइललाई सीधा अदलबदल मान्नुअघि विकल्पको ढुवानी-आवश्यकता पढ्नुहोस्।
अर्को ढुवानीले नछुने खराबीहरू
म्याद सकिएको प्रमाणपत्रलाई अझै घडी जाँच वा नवीकरण चाहिन्छ, र अस्वीकृत खातालाई अझै सही प्रमाणहरू चाहिन्छ। अपरेटरले दिएका सर्भर-पहिचान जाँचहरू राख्नुहोस्, किनकि परिचित पोर्ट नम्बरले कसैलाई प्रमाणित गर्दैन। जुन पोर्टले जवाफ दिन्छ, त्यसले केही सुनिरहेको छ भन्ने मात्र बताउँछ।
सुरुङ माथि आए पनि गन्तव्यहरू असफल भइरहे, तब बाँकी समस्या जडानपछिको राउटिङ वा नाम-समाधान हो, ढुवानी होइन। पोर्ट फेर्दै घुम्नुको सट्टा त्यो बाटो पछ्याउनुहोस्, किनकि यसरी नै एउटा दिउँसो हराउँछ। प्रोफाइलले कुन ढुवानी प्रयास गर्ने बताउँछ; UDP बाटो किन असफल भयो भनेर यसले कहिल्यै बताउँदैन।