proto udp की tcp-client: तुमचा सर्व्हर कोणते ऐकतो?

गेल्या महिन्यात चालणारी प्रोफाइल आता वेळ संपून जाते, आणि कोणी proto udp च्या जागी proto tcp-client वापरण्याचा सल्ला देतो. कधी तो योग्य निर्णय असतो, आणि कधी अशा क्लायंट तयार होतो जो अशा पोर्टशी जोडतो जिथे काहीही ऐकत नाही, कारण सर्व्हर कधीच दुसऱ्या वाहतुकीसाठी संरचित केला नव्हता. हा निर्देश तुमची बाजू कशी बोलते हे सांगतो; तो पलीकडे श्रोता तयार करू शकत नाही. दोन्हींपैकी काहीही बदलण्यापूर्वी प्रोफाइल आणि सर्व्हर एकत्र वाचा.

निवडलेले कनेक्शन वापरते ती वाहतूक वाचा

प्रोफाइलमध्ये अनेक remote नोंदी असू शकतात, आणि प्रत्येक आपली स्वतःची वाहतूक सांगू शकते. क्लायंट त्यांना क्रमाने हाताळतो, त्यामुळे तुम्ही प्रथम दिसणारी ओळ लागू होणारी असेलच असे नाही.

प्रत्यक्षात प्रयत्न केली जाणारी नोंद शोधा, मग तिची वाहतूक वाचा. क्रम महत्त्वाचा आहे, कारण क्लायंट गुपचूप पुढीलकडे जात नाही. काही बिल्ड पुढील नोंद केवळ वेळ संपल्यानंतरच करतात, त्यामुळे फाइलच्या तळाशी असलेला कार्यरत पर्याय अपेक्षेपेक्षा काही सेकंद उशिरा गाठला जातो. पहिली ओळ जिंकली असे गृहीत धरण्याऐवजी लॉगमध्ये कोणता टोकाचा बिंदू प्रयत्न केला जातो ते पहा.

फाइलमध्ये वर एक proto ओळ आणि खाली अनेक remote नोंदी असतील, तर ती ओळ तिच्यावर मात न करणाऱ्या कोणत्याही remote साठी डीफॉल्ट आहे. डीफॉल्टमध्ये स्थानिक बदल स्वतःची वाहतूक सांगणाऱ्या remote नोंदीसाठी काहीही करत नाही.

grep -nE '^(remote|proto)\b' client.ovpn

UDP आणि TCP वेगाची सेटिंग नाहीत

UDP क्रमबद्ध प्रवाह न तयार करता डेटाग्राम पाठवतो, त्यामुळे बोगद्याची स्वतःची वाहतूक दुसऱ्या विश्वासार्ह वाहतुकीत गुंडाळली जात नाही. TCP तुम्हाला UDP टाकून देणाऱ्या किंवा अडवणाऱ्या नेटवर्कमधून मार्ग देतो, पण त्याची किंमत नेस्टेड पुनर्पाठवणी आहे जी हानी असलेली लिंक अधिक वाईट वाटू शकते.

ही उपलब्धतेची देवाणघेवाण आहे, सार्वत्रिक क्रमवारी नाही. योग्य निवड ती आहे जी क्लायंटसमोरचे नेटवर्क परवानगी देते. VPN पोर्टवर UDP टाकून देणारा मार्ग प्रोफाइल कितीही चांगले लिहिलेले असले तरी कधीच वाटाघाटी करणार नाही. मार्ग तपासा, मग वाहतूक निवडा.

त्यांच्यात केवळ मोजमापाच्या आधारे निवड करणे चूक आहे, कारण उत्तर तुमच्यासमोरचे नेटवर्क काय परवानगी देते यावर अवलंबून आहे. हॉटेल किंवा कॉर्पोरेट प्रॉक्सी 443 वर केवळ बाहेर जाणारे TCP परवानगी देऊ शकते आणि दुसरे काहीही नाही, म्हणून पुरवठादार तो प्रकार देतात. पोर्ट क्रमांक परिचित असला तरी ते त्या पोर्टवरील OpenVPN कनेक्शन आहे, HTTPS सत्र नाही.

tcp-client चा प्रत्यक्ष अर्थ काय

क्लायंट-बाजूचा निर्देश TCP कनेक्शन सुरू करणाऱ्या टोकाला नाव देतो. सर्व्हर-बाजू आपले ऐकण्याचे स्वरूप वापरते, आणि क्लायंटचा शब्द सर्व्हर संरचनेत नकलल्याने अशा श्रोता तयार होतो जो कॉल होण्याची अपेक्षा करतो, स्वीकारणारा नाही.

जुळणे म्हणजे दोन्ही टोके वाहतुकीवर सहमत आहेत, एकच स्ट्रिंग सामायिक करतात असे नाही.

grep -nE '^proto\b' /etc/openvpn/server/server.conf
ss -lntp | grep openvpn

प्रोफाइल चुकीचे आहे असे गृहीत धरण्यापूर्वी सर्व्हरला विचारा तो काय ऐकत आहे. UDP श्रोता TCP सॉकेट सूचीत दिसत नाही, आणि उलटेही खरे आहे, म्हणून सामान्य दृश्याऐवजी प्रोटोकॉल-विशिष्ट दृश्य पहा.

जेव्हा प्रोफाइल आयात होते पण कधीच जोडत नाही

लगेच वेळ संपणारी आयात केलेली प्रोफाइल सामान्यतः कोणत्याही प्रमाणीकरणापूर्वी अयशस्वी होते. पॅकेट श्रोता नसलेल्या पोर्टकडे जाते, किंवा नेटवर्क ते गुपचूप टाकून देते.

मार्ग शक्य तितक्या सोप्या पद्धतीने तपासा: अयशस्वी होणाऱ्या क्लायंटसारख्याच नेटवर्कमधून, प्रोफाइल ज्याचा दावा करते त्या वाहतुकीसह त्याच होस्ट आणि पोर्टशी जोडा.

UDP तपासणीला काहीही मिळाले नाही आणि TCP तपासणी जोडली, तर सर्व्हर दुसरे वाहतूक देत आहे आणि प्रोफाइल फक्त जुने झाले आहे. दोन्हीपैकी कोणीही प्रतिसाद देत नसेल, तर समस्या वाहतूक निवडीच्या वर आहे आणि प्रोफाइलमधील कोणतेही संपादन ती सुधारणार नाही. या दोन प्रकरणांमध्ये फरक करण्यास एक मिनिट लागते आणि कधीच संबंधित नसलेल्या प्रमाणपत्र डीबगिंगचा एक तास वाचतो.

कार्यरत वाहतूक नोंदवा

एकदा संयोजन चालले, तर ते सर्व्हर, पोर्ट आणि प्रोटोकॉलसह लिहा, आणि कोणत्या नेटवर्कमधून तपासले गेले ते नोंदवा.

अन्यथा वेळ संपण्याशी सामना होणारी पुढील व्यक्ती तोच प्रयोग उलट दिशेने करेल, आणि कदाचित ठीक असलेला सर्व्हर बदलेल.

पुरवठादार दोन्ही प्रकार प्रकाशित करत असल्यास, दोन्ही फाइल्स ठेवा आणि त्यांना जुळणाऱ्या नेटवर्कनुसार लेबल लावा. स्पष्ट नाव असलेल्या दोन प्रोफाइल्स क्लायंट वाहतुकीचे त्यासाठी कधीही संरचित न केलेल्या सर्व्हर श्रोत्याशी अपघाती मिसळणे टाळतात.