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 मोड, संदेश द्वारा लिए गए पथ और सर्वर द्वारा लौटाए गए उत्तर का नाम ले सकें। वे चार तथ्य एक अस्पष्ट आउटबॉक्स समस्या को ऐसे बदलाव में बदल देते हैं जिसकी कोई समीक्षा कर सके।