فشل إرسال البريد عند اتصال 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، فإن المنفذ والوضع غير متوافقين. أصلح الوضع في العميل بدل تعطيل التحقق من الشهادة، الذي يحوّل خطأ إعداد إلى اتصال غير موثّق. الانقسام قديم بما يكفي ليكون قياسياً: TLS الضمني على المنفذ 465 هو الترتيب الموصوف في 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 الذي يستخدمه العميل، والمسار الذي سلكته الرسالة، والرد الذي أعاده الخادم. هذه الحقائق الأربع تحوّل مشكلة صندوق صادر غامضة إلى تغيير يمكن لشخص ما مراجعته.