Postfix, VPN және smarthost: кезек — firewall емес

VPN көтерілгенше поштаны кезекте ұстау — жоспарлау мәселесі, ал әдеттегі шешім Postfix-ті тоқтатып, main.cf-ті ауыстырып, қайта іске қосу. Бұл жұмыс істейді, бірақ бұл дұрыс емес пішін, өйткені ол екі талапты араластырады: жеткізуді қашан байқап көру керек және қандай желілік жол оны тасымалдай алады. Екіншісі — firewall шешімі, оны ешбір Postfix директивасы қабылдай алмайды. Екеуі бөлінгенде, әрқайсысының шағын және тексерілетін жауабы бар.

Риллейдің межелі жерін тұрақты ұстаңыз, желі шекарасында тікелей жеткізуді бұғаттаңыз және күтуді кезекке қалдырыңыз.

Адамдар біріктіретін екі талап

Риллей Postfix-ке поштаны қайда тапсыруды айтады; relayhost = [smtp.corp.example]:587 хост пен портты атайды, ал жақшалар келесі секіріс үшін MX негізіндегі таңдауды басады. Жол ядроға пакеттердің қайда бара алатынын айтады. Жол шектеуінсіз дұрыс relayhost маршруттау кестесі рұқсат еткенде Postfix-тің интернетке тікелей шығуына әлі де жол береді, ал қате relayhost-пен дұрыс firewall поштаны дұрыс емес жерге жібереді. Ешқайсысы екіншісін білдірмейді.

Транспорт карталары, жіберуші бойынша қайта анықтаулар және қосалқы риллейлер — әрқайсысы сол оқуды қажет етеді. Тұрақты relayhost конфигурацияланған әрбір жеткізу жолы оны қолданатынының дәлелі емес, ал риллейді айналып өтетін қосалқы жол — жақсырақ бүркемедегі сол ақау.

defer_transports нақты не істейді

defer_transports аталған транспорттар үшін хабарламаларды ұстап тұрады, сондықтан кезек айналымы оларға тимейінше жеткізу әрекеті жасалмайды. Бұл жоспарлау бақылауы, ал кезекті босату оны басып озады; бұл дизайн, ақау емес. master.cf-тегі нақты транспорт атауларын қолданыңыз, өйткені теңшелетін транспорт немесе бөлек аталған риллей транспорты тек оның бағдарламасы SMTP-де сөйлейтіндігінен ғана қамтылмайды. Қарапайым қайта әрекет — басқа механизм: fail-closed жолмен жеткізу әрекеттері жай ғана сәтсіз болады және кезекте қалады, ешбір кідірту директивасы қатыспайды.

Тұрақты ақаулар сыпайы күтпейді. Нашар алушы немесе қабылданбаған тіркелгі деректері туннель пайда болғанша отырудың орнына қайтады немесе қатты қате ретінде ілініп қалады, сондықтан кідіртілген поштаға толы кезек автоматты түрде қауіпсіз кезек емес.

Жолды желі қабатында міндеттеңіз

Шектеу жергілікті шығыс шекарасына немесе оқшауланған желілік атаулар кеңістігінің ішіне жатады. Ол риллейдің нақты мекенжайларын, транспорты мен портын қамтуы керек, қосылған болса IPv6-ны да, өйткені TCP 25-ті бұғаттайтын ереже 587 немесе 465 портындағы риллей үшін ештеңе істемейді. Loopback пен жергілікті жіберу жолдарын бөлек ұстаңыз, кезектің өзі жұмысын жалғастырсын. Туннель жолы жоғалғанда немесе басқа интерфейс атымен қайта пайда болғанда саясат жабық күйде қалуы керек.

Интерфейстің көтерілу оқиғасы риллейдің ол арқылы қолжетімді екенін дәлелдемейді. Сондықтан байланысты тексеріп, содан кейін кезекті босататын ілмек — кепілдік емес, қолайлық: байланыс тексеру мен жеткізу әрекеті арасында өзгеруі мүмкін.

Бір зиянсыз хабарламамен дәлелдеңіз

VPN өшірулі кезде бір зиянсыз хабарлама жіберіңіз, содан кейін кідірту себебі мен кезек ID-і үшін postqueue -p қараңыз. Көзделген жолды қалпына келтіріп, бақыланатын кезек айналымын сұраңыз, хабарламаның басқа жерге емес, риллей арқылы шығатынын бақылаңыз. Содан кейін ұшу ортасында жолды қайта үзіп, хабарламаның кезекке қайтатынын растаңыз. Үзіліс қаншаға созыла алатынын шешпес бұрын maximal_queue_lifetime-ті қарап шығыңыз, өйткені нөлдік мән шексіз сақтау емес, бір әрекетті білдіреді.

Кезектің жасын және дискінің қолданылуын қадағалаңыз. VPN-ті күтетін саясат, егер ешкім кезектің жұмадан бері өсіп жатқанын байқамаса, пошта үзілісіне айналады.

Риллейді, транспорты, firewall ережесін және өмірлік мерзімін бірге жазып алыңыз. Осы төртеуі құрылымды сипаттайды; олардың кез келгені жалғыз өзі болжамды сипаттайды.