क्या 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 मार्ग क्यों विफल हुआ।