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 मोड, संदेशाने घेतलेला मार्ग आणि सर्व्हरने परत दिलेला प्रतिसाद नावे ठेवू शकता. ती चार तथ्ये अस्पष्ट आउटबॉक्स समस्येचे कोणीतरी पुनरावलोकन करू शकेल अशा बदलात रूपांतर करतात.