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 तपासा।

मदत मागण्यापूर्वी तीन गोष्टी लिहा: तुम्ही वापरलेला पत्ता आणि त्याने उत्तर दिले का, वापरलेली वाहतूक आणि पोर्ट, आणि जे नेटवर्क अयशस्वी झाले त्याचे स्थानिक सबनेट। एकत्रितपणे ते नाव-निराकरण वाहतूक फिल्टरिंगपासून आणि पत्ता टकरीपासून वेगळे करतात, आणि पुराव्याशी संपर्कात टिकणारी कारणे हीच आहेत।