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 परीक्षण जोडियो भने, सर्भरले अर्को ट्रान्सपोर्ट दिइरहेको छ र प्रोफाइल केवल पुरानो भएको छ। यदि दुवैले जवाफ दिएनन् भने, समस्या ट्रान्सपोर्ट छनोटभन्दा माथि छ र प्रोफाइलको कुनै पनि सम्पादनले त्यसलाई सुधार्ने छैन। यी दुई अवस्था छुट्याउन एक मिनेट लाग्छ र कहिल्यै सान्दर्भिक नभएको प्रमाणपत्र डिबगिङको एक घण्टा बचाउँछ।

काम गर्ने ट्रान्सपोर्ट रेकर्ड गर्नुहोस्

एकपटक संयोजन चलेपछि, त्यसलाई सर्भर, पोर्ट र प्रोटोकलसँग लेख्नुहोस्, र कुन सञ्जालबाट परीक्षण गरियो भनेर टिप्नुहोस्।

अन्यथा समय सकिएको सामना गर्ने अर्को व्यक्तिले त्यही प्रयोग उल्टो दिशामा दोहोर्याउनेछ, र सायद ठीक भएको सर्भर बदल्नेछ।

यदि प्रदायकले दुवै प्रकार प्रकाशित गर्छ भने, दुवै फाइल राख्नुहोस् र तिनीहरू मिल्ने सञ्जालअनुसार लेबल गर्नुहोस्। स्पष्ट नाम भएका दुई प्रोफाइलले क्लाइन्ट ट्रान्सपोर्टलाई त्यसका लागि कहिल्यै कन्फिगर नगरिएको सर्भर श्रोतासँग आकस्मिक मिसिन रोक्छन्।