Postfix, VPN və smarthost: növbə firewall deyil

Poçtu VPN qalxana qədər növbədə saxlamaq planlaşdırma problemidir və adi həll Postfix-i dayandırmaq, main.cf-i dəyişmək və yenidən işə salmaqdır. Bu işləyir, amma səhv formadır, çünki iki tələbi qarışdırır: çatdırılmanın nə vaxt cəhd edilməli olduğunu və hansı şəbəkə yolunun onu daşıya biləcəyini. İkincisi firewall qərarıdır və heç bir Postfix direktivi onu verə bilməz. İkisi ayrıldıqdan sonra hər birinin kiçik və yoxlanıla bilən cavabı var.

Relay hədəfini sabit saxlayın, birbaşa çatdırılmanı şəbəkə sərhədində bloklayın və gözləməyi növbəyə buraxın.

İnsanların bir yerə birləşdirdiyi iki tələb

Relay Postfix-ə poçtu hara verməli olduğunu deyir, relayhost = [smtp.corp.example]:587 host və portu göstərir, mötərizələr isə həmin növbəti hop üçün MX əsaslı seçimi söndürür. Yol kernela paketlərin hara gedə biləcəyini deyir. Yol məhdudiyyəti olmayan düzgün relayhost, marşrut cədvəli icazə verdikdə Postfix-in internetə birbaşa çatmasına yenə imkan verir və səhv relayhost ilə düzgün firewall poçtu yanlış yerə göndərir. Heç biri digərini şərtləndirmir.

Nəqliyyat xəritələri, göndərən üzrə üstünlüklər və ehtiyat relaylar hər biri eyni oxunuşu haqq edir. Sabit relayhost hər konfiqurasiya edilmiş çatdırılma marşrutunun ondan istifadə etdiyinə sübut deyil və relayi yan keçən ehtiyat yol da eyni nasazlıqdır, sadəcə daha yaxşı kamuflyajla.

defer_transports əslində nə edir

defer_transports adlandırılmış nəqliyyatlar üçün mesajları saxlayır, beləliklə növbə dövrü onlara toxunana qədər heç bir çatdırılma cəhdi edilmir. Bu, planlaşdırma nəzarətidir və növbənin boşaldılması onu üstələyir, bu qüsur deyil, dizayndır. master.cf-dəki real nəqliyyat adlarından istifadə edin, çünki fərdi nəqliyyat və ya ayrıca adlandırılmış relay nəqliyyatı yalnız proqramı SMTP də danışdığı üçün əhatə olunmur. Adi təkrar cəhd fərqli mexanizmdir: fail-closed yol ilə çatdırılma cəhdləri sadəcə uğursuz olur və növbədə qalır, heç bir təxirə salma direktivi işə düşmür.

Daimi nasazlıqlar nəzakətlə gözləmir. Pis alıcı və ya rədd edilmiş etimadnamə tunel görünənə qədər oturmaq əvəzinə geri qaytarılır və ya sərt xəta kimi ilişib qalır, ona görə təxirə salınmış poçtla dolu növbə avtomatik olaraq təhlükəsiz növbə deyil.

Yolu şəbəkə qatında tətbiq edin

Məhdudiyyət yerli çıxış sərhədinə və ya təcrid olunmuş şəbəkə ad məkanının içinə aiddir. O, relayin real ünvanlarını, nəqliyyatını və portunu, aktivdirsə IPv6-nı da əhatə etməlidir, çünki TCP 25-i bloklayan qayda 587 və ya 465-dəki relay üçün heç nə etmir. Loopback və yerli göndərmə yollarını ayrı saxlayın ki, növbənin özü işləməyə davam etsin. Siyasət tunel marşrutu yox olduqda və ya başqa interfeys adı altında yenidən göründükdə bağlı qalmalıdır.

İnterfeysin qalxması hadisəsi relayin ondan keçərək əlçatan olduğunu sübut etmir. Ona görə əlaqəni yoxlayıb sonra növbəni boşaldan qarmaq zəmanət deyil, rahatlıqdır: əlaqə yoxlama ilə çatdırılma cəhdi arasında dəyişə bilər.

Bir zərərsiz mesajla sübut edin

VPN söndürülmüş halda bir zərərsiz mesaj göndərin, sonra təxirə salma səbəbi və növbə ID-si üçün postqueue -p çıxışına baxın. Nəzərdə tutulan yolu bərpa edin və nəzarətli növbə dövrü tələb edin, mesajın başqa yerə deyil, relaydən keçərək getdiyini izləyin. Sonra yolu yenidən uçuş ortasında qırın və mesajın növbəyə qayıtdığını təsdiqləyin. Fasilənin nə qədər davam edə biləcəyinə qərar verməzdən əvvəl maximal_queue_lifetime dəyərinə baxın, çünki sıfır dəyər sonsuz saxlama deyil, bir cəhd deməkdir.

Növbənin yaşını və disk istifadəsini izləyin. VPN-i gözləyən siyasət, cümə günündən bəri növbənin böyüdüyünü heç kim görməsə, poçt kəsilməsinə çevrilir.

Relayi, nəqliyyatı, firewall qaydasını və ömrü birlikdə qeyd edin. Bu dördü quruluşu təsvir edir, onlardan hər hansı biri tək başına isə yalnız təxmini təsvir edir.