Postfix, VPN і smarthost: чарга не з’яўляецца фэйрволам

Трымаць пошту ў чарзе, пакуль не ўзнімецца VPN, — гэта задача планавання, і звычайнае рашэнне — спыніць Postfix, замяніць main.cf і запусціць яго зноў. Гэта працуе, і гэта няправільная форма, бо яна змешвае дзве патрабаванні: калі трэба спрабаваць дастаўку і які сеткавы шлях можа яе несці. Другое — рашэнне фэйрвола, і ніякая дырэктыва Postfix не можа яго прыняць. Калі дзве раздзяліць, кожная атрымае маленькі і правяральны адказ.

Трымайце прызначэнне рэлея стабільным, блакуйце прамую дастаўку на мяжы сеткі і дазвольце чарзе чакаць.

Дзве патрабаванні, якія людзі зліваюць у адну

Рэлей паведамляе Postfix, куды перадаваць пошту; relayhost = [smtp.corp.example]:587 называе хост і порт, а дужкі адключаюць выбар праз MX для гэтага наступнага кроку. Шлях паведамляе ядру, куды пакетам дазволена ісці. Карэктны relayhost без абмежавання шляху ўсё яшчэ дазваляе Postfix выходзіць у інтэрнэт напрамую, калі табліца маршрутызацыі гэта дазваляе, а карэктны фэйрвол з няправільным relayhost адпраўляе пошту не туды. Ні адно з другога не вынікае.

Транспартныя карты, перавызначэнні для асобных адпраўнікоў і рэзервовыя рэлеі заслугоўваюць таго ж чытання. Стабільны relayhost не з’яўляецца доказам, што кожны наладжаны маршрут дастаўкі выкарыстоўвае яго, а рэзервовы шлях, які абыходзіць рэлей, — тая ж памылка ў лепшай маскіроўцы.

Што насамрэч робіць defer_transports

defer_transports трымае паведамленні для названых транспартаў, таму спроба дастаўкі не робіцца, пакуль яе не кране праход чаргі. Гэта кіраванне планаваннем, і скід чаргі яго пераадольвае; гэта задума, а не дэфект. Выкарыстоўвайце сапраўдныя назвы транспартаў з master.cf, бо ўласны транспарт або асобна названы рэлейны транспарт не ахопліваецца толькі таму, што яго праграма таксама размаўляе па SMTP. Звычайная спроба паўтору — іншы механізм: пры шляху fail-closed спробы дастаўкі проста правальваюцца і застаюцца ў чарзе, без удзелу дырэктывы адтэрміноўкі.

Пастаянныя збоі не чакаюць ветліва. Дрэнны атрымальнік або адхіленыя ўліковыя дадзеныя вяртаюцца або застаюцца як цвёрдая памылка замест таго, каб сядзець да з’яўлення тунеля, таму чарга, поўная адтэрмінаванай пошты, не абавязкова бяспечная чарга.

Забяспечце шлях на сеткавым узроўні

Абмежаванне належыць мяжы лакальнага выхаду або ізаляванаму сеткаваму прасторы імён. Яно павінна пакрываць рэальныя адрасы рэлея, транспарт і порт, уключаючы IPv6, калі ён уключаны, бо правіла, якое блакуе TCP 25, нічога не робіць для рэлея на 587 або 465. Трымайце loopback і лакальныя шляхі адпраўкі асобна, каб сама чарга працягвала працаваць. Палітыка павінна заставацца закрытай, калі маршрут тунеля знікае або з’яўляецца зноў пад іншай назвай інтэрфейса.

Падзея ўздыму інтэрфейса не даказвае, што рэлей дасяжны праз яго. Таму хук, які правярае злучэнне і потым скідвае чаргу, — гэта зручнасць, а не гарантыя: злучэнне можа змяніцца паміж праверкай і спробай дастаўкі.

Дакажыце адным бясшкодным паведамленнем

Адпраўце адно бясшкоднае паведамленне з выключаным VPN, затым паглядзіце ў postqueue -p на прычыну адтэрміноўкі і ID чаргі. Аднавіце патрэбны шлях і запытайце кантраляваны праход чаргі, назіраючы, ці паведамленне сыходзіць праз рэлей, а не недзе іншым. Затым зноў пашкодзьце шлях падчас руху і пераканайцеся, што паведамленне вяртаецца ў чаргу. Перагледзьце maximal_queue_lifetime перад рашэннем, колькі можа доўжыцца збой, бо нуль азначае адну спробу, а не неабмежаванае захаванне.

Назірайце за ўзростам чаргі і выкарыстаннем дыска. Палітыка, якая чакае VPN, ператвараецца ў поштавы збой, калі ніхто не заўважыў, што чарга расце з пятніцы.

Запішыце рэлей, транспарт, правіла фэйрвола і тэрмін службы разам. Гэтыя чатыры апісваюць уладкаванне; любое з іх паасобку апісвае здагадку.