VPN जोडिँदा मेल सबमिशन असफल हुन्छ: चरण पत्ता लगाउनुहोस्

बिहानभर चलेको मेल टनेल माथि आउने क्षणमै रोकिन्छ, र पहिलो प्रवृत्ति पासवर्ड फेरि टाइप गर्ने हुन्छ। त्यो प्रवृत्तिले अझ उपयोगी प्रश्न छोड्छ: क्लाइन्ट सर्भरसम्म पुग्यो कि पुगेन, र प्रमाणहरू दिन सक्ने गरी अगाडि बढ्यो कि बढेन? टाइमआउट, प्रमाणपत्र त्रुटि र अस्वीकृति प्रतिक्रिया तीन फरक असफलता हुन्, र तेस्रो मात्र खातासँग सम्बन्धित छ। चरणहरू क्रममा हेर्नुहोस्, अनि VPN दोष लगाउने विषय होइन, परीक्षण गर्न सकिने चर बन्छ।

चरण 1: प्रमाणहरू छुनुअघि असफलतालाई वर्गीकृत गर्नुहोस्

एप्लिकेसनले वास्तवमै उत्पन्न गरेको त्रुटि पढ्नुहोस्, त्यसपछि त्यसलाई तीन टोकरीमध्ये एकमा राख्नुहोस्। टाइमआउट वा जडान रिसेट भन्नाले TCP मार्ग असफल भयो; TLS वा प्रमाणपत्र त्रुटि भन्नाले मार्ग चल्यो तर ह्यान्डशेक चलेन; कोडसहित SMTP प्रतिक्रिया भन्नाले मेल सर्भरले जवाफ दियो र निर्णय लियो। प्रत्येक टोकरी फरक जिम्मेवारतर्फ संकेत गर्छ।

टोकरीहरू अलग गर्न लायक छ, किनकि सुधारहरू एकअर्काको विपरीत छन्। सर्भरले प्रेषकलाई अस्वीकार गर्दा टाइमआउट बढाउनुले केही फाइदा गर्दैन, र मार्ग अवरुद्ध हुँदा पासवर्ड बदल्नुले केही गर्दैन। प्रतिक्रिया कोड सूचीमा सबैभन्दा मूल्यवान प्रमाण हो, किनकि यसले सम्पूर्ण ढुवानी शृंखला चलेको र समस्या नीति वा पहिचानको हो भन्ने प्रमाणित गर्छ। फेरि प्रयास गर्नुअघि सटीक पाठ सुरक्षित गर्नुहोस्, कुनै पनि विस्तारित स्थिति कोडसहित।

VPN बाहिर असफलता पुन: उत्पादन गर्न सक्नुहुन्न भने यहीँ रोक्नुहोस्। एउटा मेसिनमा एउटा एप्लिकेसनमा देखिने समस्या अझै नेटवर्क समस्या होइन।

चरण 2: एन्डपोइन्ट र TLS मोड पुष्टि गर्नुहोस्

सन्देश सबमिशन एउटा छुट्टै सेवा हो, सर्भर-देखि-सर्भर रिलेजस्तै एउटै कुरा होइन। सबमिशनका लागि प्रदायकको कागजातबाट होस्टनाम, पोर्ट र TLS मोड पुष्टि गर्नुहोस्, किनकि अर्को मेल सेटअपबाट लिएको परिचित पोर्ट प्रमाण होइन। पोर्ट 587 सादा पाठको अभिवादन र त्यसपछि STARTTLS अपेक्षा गर्छ, जबकि पोर्ट 465 पहिलो बाइटदेखि TLS अपेक्षा गर्छ।

openssl s_client -connect smtp.example.com:465 -servername smtp.example.com -quiet
openssl s_client -starttls smtp -connect smtp.example.com:587 -servername smtp.example.com -quiet
nc -vz smtp.example.com 587

दुईमध्ये गलत परीक्षण चलाउनु ठ्याक्कै त्यो गल्ती हो जो क्लाइन्टले अर्को मोडका लागि कन्फिगर हुँदा गर्छ। इम्प्लिसिट-TLS परीक्षण 587 मा अड्कियो भने, वा STARTTLS परीक्षण 465 मा असफल भयो भने, पोर्ट र मोड मिल्दैनन्। प्रमाणपत्र प्रमाणीकरण बन्द गर्नुको सट्टा क्लाइन्टमा मोड सुधार्नुहोस्, किनकि त्यसले कन्फिगरेसन त्रुटिलाई प्रमाणीकरण नगरिएको जडानमा बदल्छ। यो विभाजन मानक बन्ने हदसम्म पुरानो छ: पोर्ट 465 मा इम्प्लिसिट TLS RFC 8314 मा वर्णन गरिएको व्यवस्था हो।

यहाँ प्रमाणपत्र त्रुटि बाधा होइन, सूचना हो। यसले सर्भरले प्रस्तुत गरेको पहिचान र क्लाइन्टले अपेक्षा गरेको पहिचान नाम दिन्छ, र दुवैलाई जडान कमजोर नबनाई सुधार्न सकिन्छ।

चरण 3: खाता नबदली मार्गहरू तुलना गर्नुहोस्

एन्डपोइन्ट, खाता र क्लाइन्ट सेटिङ स्थिर राख्नुहोस् र मार्ग मात्र बदल्नुहोस्। एकचोटि टनेल तल हुँदा र एकचोटि माथि हुँदा पठाउनुहोस्, र सर्भरले देख्ने मार्ग र स्रोत ठेगाना अभिलेख गर्नुहोस्। असफलता मार्ग पछ्याउँछ भने तपाईंले यसलाई अलग गर्नुभयो; मेसिन पछ्याउँछ भने अलग गर्नुभएन।

ip route get smtp.example.com
curl -v --ssl-reqd --url smtp://smtp.example.com:587 --user "$SMTP_USER" \
  --mail-from [email protected] --mail-rcpt [email protected] --upload-file msg.txt

पूर्ण टनेलले प्रदायकले देख्ने स्रोत ठेगाना बदल्छ, र केही प्रदायकले अपरिचित स्रोतलाई अपरिचित पासवर्डभन्दा कडा व्यवहार गर्छन्। त्यो उनीहरूको पक्षको नीति निर्णय हो, र त्यो ग्रेलिस्ट, दर सीमा वा ब्लक हुन सक्छ। एउटा प्रदायकबाट सबैमा सामान्यीकरण नगर्नुहोस्, र हराएको NAT नियमले हरेक असफलताको व्याख्या गर्छ भनी नमान्नुहोस्। curl लगले कुन चरण असफल भयो देखाउँछ, एप्लिकेसनको आफ्नै लगले नदेखाए पनि।

टनेलले इन्टरनेट ट्राफिक बोक्ने हो भने, त्यसको राउटिङ र त्यसको एग्रेस नीति दुवैले यो गन्तव्य अनुमति दिनुपर्छ। केवल निजी मार्ग बोक्ने टनेलले मेल जडानलाई स्थानीय मार्गमा छोड्छ, जो फरक तुलना हो।

चरण 4: एउटा हानिरहित सन्देश पठाउनुहोस् र प्रतिक्रिया अभिलेख गर्नुहोस्

असफल भएको चरण सुधार्नुहोस्, त्यसपछि वेबमेल पृष्ठको सट्टा त्यही एप्लिकेसनबाट एउटा हानिरहित सन्देश सबमिट गर्नुहोस्। तपाईं एप्लिकेसनको आफ्नै पठाउने मार्ग परीक्षण गर्दै हुनुहुन्छ, त्यसका भण्डारित सेटिङ र TLS मोडसहित। वेबमेल सत्रले यसबारे केही प्रमाणित गर्दैन।

प्रतिक्रिया, पोर्ट, TLS मोड र तपाईंले प्रयोग गरेको मार्ग अभिलेख गर्नुहोस्, ताकि अर्को व्यक्तिले नतिजा पुन: उत्पादन गर्न सकोस्। चल्ने ब्राउजर र हरियो VPN आइकन अन्य कुराको अवलोकन हुन्। सन्देश पुग्यो भने, बाँकी काम त्यो कन्फिगरेसनलाई यो खाताबाट पठाउने हरेक मेसिनको पूर्वनिर्धारित बनाउनु हो।

चेकलिस्ट तब पूरा हुन्छ जब तपाईं असफल चरण, क्लाइन्टले प्रयोग गर्ने पोर्ट र TLS मोड, सन्देशले लिएको मार्ग र सर्भरले फर्काएको प्रतिक्रिया नाम दिन सक्नुहुन्छ। ती चार तथ्यले अस्पष्ट आउटबक्स समस्यालाई कसैले समीक्षा गर्न सक्ने परिवर्तनमा बदल्छन्।