Postfix, VPN va smarthost: navbat firewall emas

VPN ko'tarilguncha xatni navbatda ushlab turish rejalashtirish muammosi, odatiy yechim esa Postfixni to'xtatib, main.cfni almashtirib, qayta ishga tushirishdir. Bu ishlaydi va bu noto'g'ri shakl, chunki u ikki talabni aralashtiradi: yetkazish qachon sinab ko'rilishi va qaysi tarmoq yo'li uni tashiy olishi. Ikkinchisi firewall qarori, va hech bir Postfix direktivasi uni qabul qila olmaydi. Ikkalasi ajratilgach, har birining kichik va tekshirsa bo'ladigan javobi bor.

Relay manzilini barqaror tuting, tarmoq chegarasida to'g'ridan-to'g'ri yetkazishni bloklang va kutishni navbatga qoldiring.

Odamlar bir joyga birlashtiradigan ikki talab

Relay Postfixga xatni qayerga topshirishni aytadi; relayhost = [smtp.corp.example]:587 xost va portni ko'rsatadi, qavslar esa keyingi sakrash uchun MX asosidagi tanlovni bostiradi. Yo'l yadroga paketlar qayerga borishi mumkinligini aytadi. Yo'l cheklovisiz to'g'ri relayhost ham marshrut jadvali ruxsat berganda Postfixning internetga to'g'ridan-to'g'ri chiqishiga yo'l qo'yadi, noto'g'ri relayhost bilan to'g'ri firewall esa xatni noto'g'ri joyga yuboradi. Hech biri ikkinchisini bildirmaydi.

Transport xaritalari, har bir jo'natuvchi bo'yicha almashtirishlar va zaxira relaylar har biri bir xil o'qishga loyiq. Barqaror relayhost har bir sozlangan yetkazish yo'li undan foydalanishining isboti emas, relayni chetlab o'tuvchi zaxira yo'l esa yaxshiroq niqobdagi o'sha nosozlikdir.

defer_transports aslida nima qiladi

defer_transports nomlangan transportlar uchun xabarlarni ushlab turadi, shuning uchun navbatning bir aylanishi ularga tegmaguncha hech qanday yetkazish urinishi qilinmaydi. Bu rejalashtirish nazorati, va navbatni bo'shatish uni bekor qiladi; bu dizayn, nuqson emas. master.cf dagi haqiqiy transport nomlaridan foydalaning, chunki maxsus transport yoki alohida nomlangan relay transport faqat dasturi SMTP ham gapirgani uchun qamrab olinmaydi. Odatiy qayta urinish boshqa mexanizm: fail-closed yo'l bilan yetkazish urinishlari shunchaki muvaffaqiyatsiz bo'lib navbatda qoladi, hech qanday kechiktirish direktivasi qatnashmaydi.

Doimiy nosozliklar xushmuomalalik bilan kutmaydi. Yomon qabul qiluvchi yoki rad etilgan hisob ma'lumotlari tunnel paydo bo'lguncha o'tirish o'rniga qaytadi yoki qattiq xato sifatida tiqilib qoladi, shuning uchun kechiktirilgan xat bilan to'la navbat avtomatik xavfsiz navbat emas.

Yo'lni tarmoq qatlamida talab qiling

Cheklov mahalliy chiqish chegarasiga yoki izolyatsiya qilingan tarmoq nomlar fazosiga tegishli. U relayning haqiqiy manzillarini, transportni va portni qamrashi kerak, yoqilgan bo'lsa IPv6ni ham, chunki TCP 25ni bloklovchi qoida 587 yoki 465 dagi relay uchun hech narsa qilmaydi. Loopback va mahalliy topshirish yo'llarini alohida tuting, navbatning o'zi ishlashda davom etsin. Tunnel yo'li yo'qolganda yoki boshqa interfeys nomi ostida qayta paydo bo'lganda siyosat yopiq qolishi kerak.

Interfeysning ko'tarilish hodisasi relay uning orqali yetib borishini isbotlamaydi. Shuning uchun bog'lanishni tekshirib, so'ng navbatni bo'shatadigan ilgak qulaylik, kafolat emas: bog'lanish tekshiruv va yetkazish urinishi orasida o'zgarishi mumkin.

Bitta zararsiz xabar bilan isbotlang

VPN past bo'lganda bitta zararsiz xabar yuboring, so'ng kechikish sababi va navbat IDsi uchun postqueue -p buyrug'ini ko'rib chiqing ko'rib chiqing. Mo'ljallangan yo'lni tiklang va nazoratli navbat aylanishini so'rang, xabar boshqa joyga emas, relay orqali chiqishini kuzating. So'ng parvoz o'rtasida yo'lni yana uzib, xabar navbatga qaytishini tasdiqlang. Uzilish qancha davom etishi mumkinligini hal qilishdan oldin maximal_queue_lifetime qiymatini ko'rib chiqing, chunki nol qiymat cheksiz saqlash emas, bitta urinish demakdir.

Navbatning yoshi va disk iste'molini kuzatib boring. VPNni kutayotgan siyosat, hech kim navbat juma kunidan beri o'sayotganini sezmasa, xat uzilishiga aylanadi.

Relayni, transportni, firewall qoidasini va umrni birga yozib qo'ying. O'sha to'rttasi tartibni tasvirlaydi; ulardan har biri yolg'iz taxminni tasvirlaydi.