VPN qoşulanda poçt göndərişi uğursuz olur: mərhələni tapın

Bütün səhər işləyən poçt tunel qalxan anda dayanır və ilk instinkt parolu yenidən yazmaqdır. Bu instinkt daha faydalı sualı atlayır: müştəri serverə ümumiyyətlə çatdımı və etimad məlumatlarını təqdim edəcək qədər irəli getdimi? Taym-aut, sertifikat xətası və rədd cavabı üç fərqli uğursuzluqdur və yalnız üçüncüsü hesabla bağlıdır. Mərhələləri sıra ilə işləyin və VPN günahlandırdığınız şübhəli deyil, sınaqdan keçirə biləcəyiniz dəyişənə çevrilsin.

Addım 1: etimad məlumatlarına toxunmadan uğursuzluğu təsnif edin

Tətbiqin həqiqətən yaratdığı xətanı oxuyun, sonra onu üç qutudan birinə qoyun. Taym-aut və ya bağlantının sıfırlanması TCP yolunun uğursuz olduğunu bildirir; TLS və ya sertifikat xətası yolun işlədiyini, əl sıxışmasının işləmədiyini bildirir; kodlu SMTP cavabı poçt serverinin cavab verdiyini və qərar qəbul etdiyini bildirir. Hər qutu fərqli sahibə işarə edir.

Qutuları ayırmağa dəyər, çünki düzəlişlər bir-birinə ziddir. Server göndərəni rədd edəndə taym-autu uzatmaq heç nəyə kömək etmir və marşrut qara dəliyə düşəndə parolu dəyişmək heç nə etmir. Cavab kodu siyahıdakı ən dəyərli sübutdur, çünki bütün nəqliyyat zəncirinin işlədiyini və problemin siyasət və ya kimlik olduğunu sübut edir. Yenidən cəhd etməzdən əvvəl dəqiq mətni, o cümlədən hər hansı genişləndirilmiş status kodunu saxlayın.

Uğursuzluğu VPN-dən kənarda təkrarlaya bilmirsinizsə, burada dayanın. Bir maşında bir tətbiqdə görünən problem hələ şəbəkə problemi deyil.

Addım 2: son nöqtəni və TLS rejimini təsdiqləyin

Mesaj göndərişi ayrı bir xidmətdir, serverdən serverə ötürmə ilə eyni şey deyil. Host adını, portu və TLS rejimini provayderin göndəriş üçün sənədlərindən təsdiqləyin, çünki başqa poçt quruluşundan götürülmüş tanış port sübut deyil. Port 587 düz mətn salamlama və ardınca STARTTLS gözləyir, port 465 isə ilk baytdan TLS gözləyir.

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

Bu iki yoxlamadan səhv olanı işə salmaq, müştərinin digər rejim üçün konfiqurasiya edildikdə etdiyi dəqiq səhvdir. Əgər gizli TLS yoxlaması 587-də asılırsa və ya STARTTLS yoxlaması 465-də uğursuz olursa, port və rejim uyğun gəlmir. Sertifikat yoxlamasını söndürmək əvəzinə rejimi müştəridə düzəldin, çünki bu, konfiqurasiya xətasını yoxlanılmamış bağlantıya çevirir. Bu bölgü standartlaşdırılacaq qədər köhnədir: port 465-də gizli TLS RFC 8314-də təsvir olunan düzümdür.

Burada sertifikat xətası maneə deyil, məlumatdır. O, serverin təqdim etdiyi kimliyi və müştərinin gözlədiyi kimliyi adlandırır və hər ikisi bağlantını zəiflətmədən düzəldilə bilər.

Addım 3: hesabı dəyişmədən yolları müqayisə edin

Son nöqtəni, hesabı və müştəri parametrlərini sabit saxlayın və yalnız yolu dəyişin. Bir dəfə tunel bağlı, bir dəfə açıq göndərin və marşrutu və serverin görəcəyi mənbə ünvanını qeyd edin. Uğursuzluq yolu izləyirsə, onu təcrid etmisiniz; maşını izləyirsə, etməmisiniz.

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 tunel provayderin gördüyü mənbə ünvanını dəyişir və bəzi provayderlər tanış olmayan mənbəyə tanış olmayan paroldan daha sərt yanaşır. Bu onların tərəfində siyasət qərarıdır və boz siyahı, sürət limiti və ya blok ola bilər. Bir provayderdən hamıya ümumiləşdirməyin və çatışmayan NAT qaydasının hər uğursuzluğu izah etdiyini güman etməyin. curl protokolu hansı mərhələnin uğursuz olduğunu tətbiqin öz jurnalı göstərməsə belə göstərir.

Tunel internet trafikini daşımalıdırsa, həm marşrutlaşdırma, həm də çıxış siyasəti bu təyinat nöqtəsinə icazə verməlidir. Yalnız şəxsi marşrutları daşıyan tunel poçt bağlantısını lokal yolda qoyur ki, bu da fərqli müqayisədir.

Addım 4: bir zərərsiz mesaj göndərin və cavabı qeyd edin

Uğursuz olan mərhələni düzəldin, sonra veb-poçt səhifəsi ilə deyil, eyni tətbiq vasitəsilə bir zərərsiz mesaj göndərin. Sınadığınız tətbiqin öz göndərmə yoludur, o cümlədən saxlanmış parametrləri və TLS rejimi. Veb-poçt sessiyası bu barədə heç nə sübut etmir.

Cavabı, portu, TLS rejimini və istifadə etdiyiniz yolu qeyd edin ki, növbəti şəxs nəticəni təkrarlaya bilsin. İşləyən brauzer və yaşıl VPN ikonası başqa şeylər haqqında müşahidələrdir. Mesaj çatırsa, qalan iş bu konfiqurasiyanı bu hesabla göndərən hər maşın üçün standart etməkdir.

Yoxlama siyahısı uğursuz olan mərhələni, müştərinin istifadə etdiyi portu və TLS rejimini, mesajın getdiyi yolu və serverin qaytardığı cavabı adlandıra bildiyiniz zaman tamamlanır. Bu dörd fakt qeyri-müəyyən çıxış qutusu problemini kiminsə nəzərdən keçirə biləcəyi dəyişikliyə çevirir.