Pengiriman email gagal saat VPN tersambung: temukan tahapnya

Email yang berjalan sepanjang pagi berhenti tepat saat terowongan naik, dan naluri pertama adalah mengetik ulang kata sandi. Naluri itu melewatkan pertanyaan yang lebih berguna: apakah klien sama sekali mencapai server, dan apakah ia cukup jauh untuk menawarkan kredensial? Batas waktu, kesalahan sertifikat, dan balasan penolakan adalah tiga kegagalan berbeda, dan hanya yang ketiga menyangkut akun. Telusuri tahapannya secara berurutan dan VPN menjadi variabel yang dapat diuji, bukan tersangka yang disalahkan.

Langkah 1: klasifikasikan kegagalan sebelum menyentuh kredensial

Baca kesalahan yang benar-benar dihasilkan aplikasi, lalu letakkan di salah satu dari tiga keranjang. Batas waktu atau reset koneksi berarti jalur TCP gagal; kesalahan TLS atau sertifikat berarti jalur berhasil dan jabat tangan tidak; balasan SMTP dengan kode berarti server email menjawab dan mengambil keputusan. Setiap keranjang menunjuk ke penanggung jawab yang berbeda.

Keranjang itu layak dipisahkan karena perbaikannya saling bertentangan. Memperpanjang batas waktu tidak membantu ketika server menolak pengirim, dan mengganti kata sandi tidak melakukan apa pun ketika jalurnya diblokir. Kode balasan adalah bukti paling berharga dalam daftar, karena membuktikan seluruh rantai transportasi berhasil dan masalahnya ada pada kebijakan atau identitas. Simpan teks persisnya, termasuk kode status yang diperluas, sebelum mencoba lagi.

Berhenti di sini jika Anda tidak dapat mereproduksi kegagalan di luar VPN. Masalah yang muncul di satu aplikasi pada satu mesin belum menjadi masalah jaringan.

Langkah 2: pastikan titik akhir dan mode TLS

Pengiriman pesan adalah layanan tersendiri, bukan hal yang sama dengan relai antar-server. Pastikan nama host, port, dan mode TLS dari dokumentasi penyedia untuk pengiriman, karena port yang dikenal tetapi dipinjam dari konfigurasi email lain bukanlah bukti. Port 587 mengharapkan sapaan teks biasa yang diikuti STARTTLS, sedangkan port 465 mengharapkan TLS sejak byte pertama.

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

Menjalankan salah satu dari dua uji itu adalah tepat kesalahan yang dilakukan klien ketika dikonfigurasi untuk mode lain. Jika uji TLS implisit macet pada 587, atau uji STARTTLS gagal pada 465, port dan mode tidak cocok. Perbaiki mode di klien alih-alih menonaktifkan verifikasi sertifikat, yang mengubah kesalahan konfigurasi menjadi koneksi tanpa verifikasi. Pemisahan ini cukup tua untuk distandarkan: TLS implisit pada port 465 adalah susunan yang dijelaskan di RFC 8314.

Kesalahan sertifikat di sini adalah informasi, bukan hambatan. Kesalahan itu menyebutkan identitas yang disajikan server dan identitas yang diharapkan klien, dan keduanya dapat diperbaiki tanpa melemahkan koneksi.

Langkah 3: bandingkan jalur tanpa mengubah akun

Jaga titik akhir, akun, dan pengaturan klien tetap dan ubah hanya jalurnya. Kirim sekali dengan terowongan mati dan sekali dengan terowongan hidup, lalu catat rute dan alamat sumber yang akan dilihat server. Jika kegagalan mengikuti jalurnya, Anda telah mengisolasinya; jika mengikuti mesinnya, belum.

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

Terowongan penuh mengubah alamat sumber yang dilihat penyedia, dan sebagian penyedia memperlakukan sumber yang tidak dikenal lebih ketat daripada kata sandi yang tidak dikenal. Itu keputusan kebijakan di pihak mereka, dan bisa berupa daftar abu-abu, batas laju, atau blokir. Jangan menggeneralisasi dari satu penyedia ke semua, dan jangan menganggap aturan NAT yang hilang menjelaskan setiap kegagalan. Transkrip curl menunjukkan tahap mana yang gagal bahkan ketika log aplikasi sendiri tidak menunjukkannya.

Jika terowongan seharusnya membawa lalu lintas internet, perutean dan kebijakan keluarnya harus sama-sama mengizinkan tujuan ini. Terowongan yang hanya membawa rute privat meninggalkan koneksi email di jalur lokal, yang merupakan perbandingan berbeda.

Langkah 4: kirim satu pesan tak berbahaya dan catat balasannya

Perbaiki tahap yang gagal, lalu kirim satu pesan tak berbahaya melalui aplikasi yang sama, bukan melalui halaman webmail. Yang Anda uji adalah jalur pengiriman aplikasi itu sendiri, termasuk pengaturan tersimpannya dan mode TLS-nya. Sesi webmail tidak membuktikan apa pun tentang itu.

Catat balasan, port, mode TLS, dan jalur yang Anda gunakan, agar orang berikutnya dapat mereproduksi hasilnya. Peramban yang berfungsi dan ikon VPN hijau adalah pengamatan tentang hal lain. Jika pesan tiba, pekerjaan yang tersisa adalah menjadikan konfigurasi itu bawaan untuk setiap mesin yang mengirim melalui akun ini.

Daftar periksa lengkap ketika Anda dapat menyebutkan tahap yang gagal, port dan mode TLS yang digunakan klien, jalur yang ditempuh pesan, dan balasan yang dikembalikan server. Keempat fakta itu mengubah masalah kotak keluar yang kabur menjadi perubahan yang dapat ditinjau seseorang.