ارسال ایمیل هنگام اتصال 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 مورد استفاده کارخواه، مسیری که پیام طی کرد و پاسخی که کارساز برگرداند را نام ببرید. این چهار واقعیت مشکل مبهم صندوق خروجی را به تغییری تبدیل می‌کند که کسی می‌تواند بازبینی کند.