Postfix, VPN a smarthost: fronta není firewall

Držet poštu ve frontě, dokud se VPN nezvedne, je problém plánování a obvyklé řešení je zastavit Postfix, vyměnit main.cf a znovu ho spustit. Funguje to a je to špatný tvar, protože to míchá dva požadavky: kdy se má doručení zkusit a která síťová cesta ho smí nést. Druhý je rozhodnutí firewallu a žádná direktiva Postfixu ho nemůže udělat. Jakmile se oba oddělí, každý má malou a testovatelnou odpověď.

Držte cíl relaye stabilní, zablokujte přímé doručení na síťové hranici a nechte frontu čekat.

Dva požadavky, které lidé slévají v jeden

Relay říká Postfixu, kam poštu předat; relayhost = [smtp.corp.example]:587 určuje hostitele a port, přičemž hranaté závorky potlačují výběr podle MX pro tento další skok. Cesta říká jádru, kam smějí pakety jít. Správný relayhost bez omezení cesty stále nechá Postfix dosáhnout internetu přímo, když to směrovací tabulka dovolí, a správný firewall s chybným relayhostem posílá poštu na špatné místo. Ani jedno nevyplývá z druhého.

Transportní mapy, výjimky pro jednotlivé odesílatele i záložní relaye si zaslouží stejné čtení. Stabilní relayhost není důkaz, že ho používá každá nakonfigurovaná trasa doručení, a záložní trasa, která relay obchází, je stejná závada v lepším maskování.

Co defer_transports skutečně dělá

defer_transports zadržuje zprávy pro pojmenované transporty, takže se neprovede žádný pokus o doručení, dokud se jich nedotkne průchod fronty. Je to řízení plánování a vyprázdnění fronty ho přebije; to je záměr, ne vada. Používejte skutečné názvy transportů z master.cf, protože vlastní transport nebo jinak pojmenovaný relay transport není pokryt jen proto, že jeho program také mluví SMTP. Běžný opakovaný pokus je jiný mechanismus: při fail-closed cestě pokusy o doručení prostě selžou a zůstanou ve frontě, bez účasti direktivy odkladu.

Trvalé chyby nečekají zdvořile. Špatný příjemce nebo odmítnuté přihlašovací údaje se vrátí nebo uváznou jako tvrdá chyba místo toho, aby seděly, dokud se neobjeví tunel, takže fronta plná odložené pošty není automaticky bezpečná fronta.

Vynuťte cestu na síťové vrstvě

Omezení patří na hranici lokálního výstupu nebo dovnitř izolovaného síťového namespace. Musí pokrýt skutečné adresy relaye, transport a port, včetně IPv6, je-li zapnutý, protože pravidlo blokující TCP 25 nedělá nic pro relay na 587 nebo 465. Držte loopback a cesty lokálního podání oddělené, aby samotná fronta fungovala dál. Politika by měla zůstat zavřená, když trasa tunelu zmizí nebo se znovu objeví pod jiným názvem rozhraní.

Událost, kdy rozhraní nabyde stavu nahoru, nedokazuje, že je relay přes něj dostupný. Proto je hook, který zkontroluje spojení a pak frontu vyprázdní, pohodlí, nikoli záruka: spojení se může změnit mezi kontrolou a pokusem o doručení.

Dokažte to jednou neškodnou zprávou

Pošlete jednu neškodnou zprávu s vypnutou VPN, poté prohlédněte postqueue -p kvůli důvodu odkladu a ID fronty. Obnovte zamýšlenou cestu a vyžádejte řízený průchod fronty, přičemž sledujte, zda zpráva odchází přes relay, a ne někam jinam. Pak cestu znovu přerušte za letu a potvrďte, že se zpráva vrací do fronty. Před rozhodnutím, jak dlouho může výpadek trvat, projděte maximal_queue_lifetime, protože nulová hodnota znamená jeden pokus, nikoli neomezené zadržení.

Sledujte stáří fronty a využití disku. Politika, která čeká na VPN, se změní ve výpadek pošty, pokud si nikdo nevšimne, že fronta roste od pátku.

Zaznamenejte relay, transport, pravidlo firewallu a životnost společně. Ty čtyři popisují uspořádání; kterékoli z nich samo popisuje jen dohad.