VPN bağlandığında posta gönderimi başarısız oluyor: aşamayı bulun

Bütün sabah çalışan posta, tünel açıldığı anda durur ve ilk tepki parolayı yeniden yazmaktır. Bu tepki daha yararlı soruyu atlar: istemci sunucuya ulaştı mı ve kimlik bilgilerini sunacak kadar ilerledi mi? Zaman aşımı, sertifika hatası ve ret yanıtı üç farklı arızadır ve yalnızca üçüncüsü hesabı ilgilendirir. Aşamaları sırayla inceleyin, o zaman VPN suçladığınız bir şüpheli değil, test edebileceğiniz bir değişken olur.

Aşama 1: kimlik bilgilerine dokunmadan önce arızayı sınıflandırın

Uygulamanın gerçekten ürettiği hatayı okuyun ve üç kovadan birine koyun. Zaman aşımı veya bağlantı sıfırlaması TCP yolunun başarısız olduğu anlamına gelir; TLS veya sertifika hatası yolun çalıştığı, el sıkışmanın çalışmadığı anlamına gelir; kodlu bir SMTP yanıtı bir posta sunucusunun yanıt verip karar verdiği anlamına gelir. Her kova farklı bir sorumluya işaret eder.

Kovaları ayırmaya değer, çünkü düzeltmeler birbiriyle çelişir. Sunucu göndereni reddederken zaman aşımını uzatmak hiçbir işe yaramaz ve yol engelliyken parola değiştirmek hiçbir şey yapmaz. Yanıt kodu listedeki en değerli kanıttır, çünkü tüm taşıma zincirinin çalıştığını ve sorunun ilke veya kimlik olduğunu kanıtlar. Yeniden denemeden önce genişletilmiş durum kodu dahil tam metni kaydedin.

Arızayı VPN dışında yeniden üretemiyorsanız burada durun. Tek bir makinede tek bir uygulamada görünen sorun henüz bir ağ sorunu değildir.

Aşama 2: uç noktayı ve TLS modunu doğrulayın

İleti gönderimi kendi başına bir hizmettir, sunucudan sunucuya aktarımla aynı şey değildir. Gönderim için sağlayıcının belgelerinden ana bilgisayar adını, portu ve TLS modunu doğrulayın, çünkü başka bir posta yapılandırmasından ödünç alınan tanıdık bir port kanıt değildir. Port 587 düz metin bir selamlamayı ve ardından STARTTLS'i beklerken port 465 ilk bayttan itibaren TLS bekler.

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

İki testten yanlış olanı çalıştırmak, istemcinin diğer mod için yapılandırıldığında yaptığı hatanın tam kendisidir. Örtük TLS testi 587'de takılırsa veya STARTTLS testi 465'te başarısız olursa, port ve mod uyuşmaz. Sertifika doğrulamayı kapatmak yerine modu istemcide düzeltin; bu, yapılandırma hatasını doğrulanmamış bir bağlantıya dönüştürür. Bu ayrım standartlaşacak kadar eski: 465 numaralı portta örtük TLS, RFC 8314 belgesinde açıklanan düzenlemedir.

Buradaki sertifika hatası engel değil bilgidir. Sunucunun sunduğu kimliği ve istemcinin beklediği kimliği adlandırır ve ikisi de bağlantıyı zayıflatmadan düzeltilebilir.

Aşama 3: hesabı değiştirmeden yolları karşılaştırın

Uç noktayı, hesabı ve istemci ayarlarını sabit tutun ve yalnızca yolu değiştirin. Bir kez tünel kapalıyken, bir kez açıkken gönderin ve sunucunun göreceği rotayı ve kaynak adresi kaydedin. Arıza yolu izliyorsa onu yalıttınız; makineyi izliyorsa yalıtmadınız.

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

Tam tünel, sağlayıcının gördüğü kaynak adresi değiştirir ve bazı sağlayıcılar tanımadıkları kaynağa tanımadıkları paroladan daha katı davranır. Bu onların tarafındaki bir ilke kararıdır ve gri liste, hız sınırı veya blok olabilir. Bir sağlayıcıdan hepsine genelleme yapmayın ve eksik bir NAT kuralının her arızayı açıkladığını varsaymayın. curl kaydı, uygulamanın kendi günlüğü göstermese bile hangi aşamanın başarısız olduğunu gösterir.

Tünelin internet trafiğini taşıması gerekiyorsa, hem yönlendirmesi hem de çıkış ilkesi bu hedefe izin vermelidir. Yalnızca özel rotalar taşıyan bir tünel, posta bağlantısını yerel yolda bırakır; bu başka bir karşılaştırmadır.

Aşama 4: zararsız bir ileti gönderin ve yanıtı kaydedin

Başarısız olan aşamayı düzeltin, sonra webmail sayfası yerine aynı uygulama üzerinden zararsız bir ileti gönderin. Test ettiğiniz, uygulamanın kendi gönderme yoludur; kayıtlı ayarları ve TLS modu buna dahildir. Bir webmail oturumu bunun hakkında hiçbir şey kanıtlamaz.

Yanıtı, portu, TLS modunu ve kullandığınız yolu kaydedin ki bir sonraki kişi sonucu yeniden üretebilsin. Çalışan bir tarayıcı ve yeşil VPN simgesi başka şeyler hakkında gözlemlerdir. İleti ulaşırsa, geriye kalan iş bu yapılandırmayı bu hesap üzerinden gönderen her makine için varsayılan yapmaktır.

Kontrol listesi, başarısız olan aşamayı, istemcinin kullandığı portu ve TLS modunu, iletinin izlediği yolu ve sunucunun döndürdüğü yanıtı adlandırabildiğinizde tamamdır. Bu dört gerçek, belirsiz bir giden kutusu sorununu birinin inceleyebileceği bir değişikliğe dönüştürür.