क्यों एक OpenVPN प्रोफ़ाइल घर पर काम करती है लेकिन होटल में विफल हो जाती है

ऑफ़िस का Wi-Fi और होटल का कमरा एक ही लैपटॉप को दो बिल्कुल अलग नेटवर्क दे सकते हैं, और बीच की प्रोफ़ाइल को इसका कोई अंदाज़ा नहीं है। घर पर जो काम करता है वह एक उदार अपलिंक, काम करने वाला नाम-विभेदन और ऐसा स्थानीय सबनेट मान लेता है जो टनल जो कुछ भी ले जाती है उससे टकराता नहीं। इनमें से हर धारणा अलग-अलग विफल हो सकती है।

इसे डीबग करने का उपयोगी तरीका है नेटवर्क को चार अलग तथ्यों के रूप में लेना और फिर उन्हें क्रम से जाँचना। पहले प्रोफ़ाइल पर अनुमान लगाने से आम तौर पर ऐसा बदलाव आता है जो कुछ ठीक नहीं करता और सबूत छिपा देता है।

चार नेटवर्क तथ्य स्थानों के बीच बदलते हैं

पहला तथ्य यह है कि स्थानीय नेटवर्क आपको बाहर निकलने देता है या नहीं। कैप्टिव पोर्टल किसी डिवाइस को लॉगिन पृष्ठ पर ले जाता है और उस पृष्ठ के पूरा होने तक बाकी सब कुछ अवरुद्ध कर देता है, यानी प्रोफ़ाइल कितनी भी सही हो टनल शुरू नहीं हो सकती।

दूसरा नाम-विभेदन है। DNS को रोकने वाला पोर्टल हर प्रश्न का उत्तर अपने पते से देता है, इसलिए VPN का होस्टनाम पोर्टल पर विभेदित हो जाता है और क्लाइंट वेब पृष्ठ तक टनल बनाने की कोशिश करता है।

तीसरा परिवहन फ़िल्टरिंग है। जो नेटवर्क केवल ब्राउज़िंग की अनुमति देना चाहते हैं वे TCP 443 को मनमाने गंतव्यों तक जाने देते हैं और UDP सहित लगभग बाकी सब कुछ गिरा देते हैं।

चौथा एड्रेसिंग है। स्थानीय सबनेट टनल के पीछे के नेटवर्क से ओवरलैप हो सकता है, या अपलिंक कोई भी उपयोगी IPv4 पथ नहीं दे सकता।

नाम-विभेदन और कैप्टिव पोर्टल

प्रोफ़ाइल में होस्टनाम को सर्वर के संख्यात्मक पते से बदलें और फिर कोशिश करें। अगर IP जुड़ता है और नाम नहीं, तो दोष नाम-विभेदन का है, और प्रोफ़ाइल अपने आप में ठीक है।

VPN को छूने से पहले ब्राउज़र खोलें और एक सामान्य HTTP पृष्ठ खोलने का प्रयास करें। लॉगिन पृष्ठ पर रीडायरेक्ट होने का मतलब है कि पोर्टल अभी बाकी है; उसे पूरा करें, फिर दोबारा जुड़ें। कई होटल कुछ घंटों बाद सत्र भी समाप्त कर देते हैं, जो लॉगिन समस्या की बजाय दोपहर के बीच कटाव जैसा दिखता है।

अगर संख्यात्मक पता भी विफल हो, तो नाम-विभेदन स्पष्टीकरण नहीं है, इसलिए परिवहन की ओर बढ़ें। जो पता आपने जाँचा उसे रखें, क्योंकि वह अगली जाँच को बताता है कि पैकेट मशीन से निकले भी या नहीं।

परिवहन फ़िल्टरिंग: पहले UDP, बैकअप के रूप में TCP 443

UDP 1194 पर OpenVPN का प्रवाह होटल फ़ायरवॉल द्वारा पहचानी जाने वाली किसी चीज़ जैसा नहीं लगता, इसलिए इसे बिना त्रुटि के गिरा दिया जाता है। क्लाइंट अपने टाइमआउट खत्म होने तक दोबारा कोशिश करता है, और उपयोगकर्ता इनकार की बजाय ऐसा कनेक्शन देखता है जो कभी बनता ही नहीं। ऐसा व्यवहार करने वाले फ़ायरवॉल शायद ही कभी गिरावट को कहीं ऐसा लॉग करते हैं जहाँ आप उसे देख सकें। इनकार का न होना अपने आप में सुराग है।

TCP 443 विश्वसनीय बैकअप है क्योंकि नेटवर्क उसे सामान्य HTTPS से अलग नहीं कर सकता। जब ऑपरेटर की TCP प्रोफ़ाइल मौजूद हो तो उसी का उपयोग करें, क्योंकि सर्वर को भी उसी परिवहन और पोर्ट पर सुनना पड़ता है; केवल क्लाइंट बदलने से अलग तरह की विफलता होती है। अगर कोई TCP प्रोफ़ाइल न हो, तो पोर्ट संपादित करके नई गढ़ने की बजाय ऑपरेटर से पूछें। सर्वर पक्ष को भी सहमत होना चाहिए, और बेमेल फिर से फ़ायरवॉल समस्या जैसा दिखता है।

प्रदर्शन की कीमत की अपेक्षा रखें। TCP के अंदर TCP हानि वाली लिंक पर पुनःप्रेषण बढ़ाता है, इसलिए काम करने वाली TCP टनल भीड़भाड़ वाले होटल नेटवर्क पर धीमी लग सकती है। यह पहुँच के लिए सौदा है, पीछा करने योग्य खराबी नहीं।

पता टकराव और IPv4 रहित अपलिंक

टनल बन सकती है और फिर भी कुछ नहीं ढो सकती। जब स्थानीय LAN और दूर का नेटवर्क 192.168.1.0/24 जैसा उपसर्ग साझा करते हैं, तो क्लाइंट दूर के होस्ट को सीधे जुड़ा मानता है और पैकेट को टनल की बजाय स्थानीय लिंक पर भेजता है। लक्षण है एक अगम्य सबनेट के साथ सफल कनेक्शन, जिसे सर्वर-पक्ष मार्ग समस्या के रूप में आसानी से गलत पढ़ा जाता है।

स्थायी समाधान है दूर के LAN को असामान्य निजी श्रेणी में ले जाना। ऐसी श्रेणी चुनना जिसे घर पर कोई उपयोग न करता हो, जैसे 10.42.0.0/24, समस्या को एक के बजाय हर भावी स्थान के लिए रोकता है। स्थानीय जुगाड़ उस होटल, हॉटस्पॉट या राउटर से बचना है, जो कोई समाधान ही नहीं है।

मोबाइल अपलिंक दो भिन्नताएँ जोड़ते हैं। कैरियर-ग्रेड NAT का मतलब है कि आने वाले कनेक्शन नहीं पहुँचते, जो मायने रखता है अगर आप सर्वर होस्ट करते हैं पर बाहर जाने वाले क्लाइंट के लिए नहीं। NAT64 अनुवाद के साथ केवल IPv6 के रूप में सेट किया गया APN उस क्लाइंट को विफल कर सकता है जो असली IPv4 पथ पर ज़ोर देता है, और सामान्य उपाय APN प्रोटोकॉल को IPv4 या दोहरे स्टैक में बदलना है।

टनल ऊपर आने के बाद के लक्षण

जुड़कर फिर चुप हो जाने वाली टनल आम तौर पर keepalive या MTU समस्या है, अवरुद्ध पोर्ट नहीं। तय मिनटों के बाद गिरने वाला कनेक्शन keepalive या पुनःबातचीत टाइमर की ओर इशारा करता है। क्लाइंट को उसके साथी को जाँचने और जवाब रुकने पर फिर शुरू करने के लिए सेट करें, और अगर ping सफल हों पर बड़े स्थानांतरण अटकें तो छोटा टनल MTU जाँचें।

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