Postfix, VPN a smarthost: fronta nie je firewall

Držať poštu vo fronte, kým sa VPN nezvedne, je problém plánovania a obvyklé riešenie je zastaviť Postfix, vymeniť main.cf a znova ho spustiť. Funguje to, a je to nesprávny tvar, pretože to mieša dve požiadavky: kedy sa má doručenie pokúsiť a ktorá sieťová cesta ho smie niesť. Druhá je rozhodnutie firewallu a žiadna direktíva Postfixu ho nemôže urobiť. Keď sa obe oddelia, každá má malú a testovateľnú odpoveď.

Držte cieľ relayu stabilný, zablokujte priame doručenie na sieťovej hranici a nechajte frontu čakať.

Dve požiadavky, ktoré ľudia zlievajú do jednej

Relay hovorí Postfixu, kam poštu odovzdať; relayhost = [smtp.corp.example]:587 uvádza hostiteľa a port, pričom hranaté zátvorky potláčajú výber podľa MX pre tento ďalší skok. Cesta hovorí jadru, kam smú pakety ísť. Správny relayhost bez obmedzenia cesty stále nechá Postfix dosiahnuť internet priamo, keď to smerovacia tabuľka dovolí, a správny firewall s nesprávnym relayhostom posiela poštu na nesprávne miesto. Ani jedno nevyplýva z druhého.

Transportné mapy, výnimky pre jednotlivých odosielateľov aj záložné relaye si zaslúžia rovnaké čítanie. Stabilný relayhost nie je dôkaz, že ho používa každá nastavená trasa doručenia, a záložná trasa, ktorá relay obchádza, je tá istá chyba v lepšom maskovaní.

Čo defer_transports skutočne robí

defer_transports zadržiava správy pre pomenované transporty, takže sa nevykoná žiadny pokus o doručenie, kým sa ich nedotkne jeden prechod fronty. Je to riadenie plánovania a vyprázdnenie fronty ho prepíše; to je zámer, nie chyba. Používajte skutočné názvy transportov z master.cf, pretože vlastný transport alebo inak pomenovaný relay transport nie je pokrytý len preto, že jeho program hovorí aj SMTP. Bežný opakovaný pokus je iný mechanizmus: pri fail-closed ceste pokusy o doručenie jednoducho zlyhajú a zostanú vo fronte, bez účasti direktívy odkladu.

Trvalé chyby nečakajú zdvorilo. Zlý príjemca alebo odmietnuté prihlasovacie údaje sa vrátia alebo uviaznu ako tvrdá chyba namiesto toho, aby sedeli, kým sa neobjaví tunel, takže fronta plná odloženej pošty nie je automaticky bezpečná fronta.

Vynúťte cestu v sieťovej vrstve

Obmedzenie patrí na hranicu lokálneho výstupu alebo dovnútra izolovaného sieťového menného priestoru. Musí pokryť skutočné adresy relayu, transport a port, vrátane IPv6, ak je zapnuté, pretože pravidlo blokujúce TCP 25 nič nerobí pre relay na 587 alebo 465. Držte loopback a cesty lokálneho podania oddelene, aby samotná fronta fungovala ďalej. Politika by mala zostať zatvorená, keď trasa tunela zmizne alebo sa znova objaví pod iným názvom rozhrania.

Udalosť, keď rozhranie nabehne, nedokazuje, že relay je cez neho dostupný. Preto je hák, ktorý skontroluje spojenie a potom frontu vyprázdni, pohodlie, nie záruka: spojenie sa môže zmeniť medzi kontrolou a pokusom o doručenie.

Dokážte to jednou neškodnou správou

Pošlite jednu neškodnú správu s vypnutou VPN, potom prezrite postqueue -p kvôli dôvodu odkladu a ID fronty. Obnovte zamýšľanú cestu a požiadajte o riadený prechod fronty, pričom sledujte, či správa odchádza cez relay a nie niekam inam. Potom cestu znova prerušte počas letu a potvrďte, že sa správa vracia do fronty. Prezrite maximal_queue_lifetime, kým rozhodnete, ako dlho môže výpadok trvať, pretože nulová hodnota znamená jeden pokus, nie neobmedzené uchovávanie.

Sledujte vek fronty a využitie disku. Politika, ktorá čaká na VPN, sa zmení na výpadok pošty, ak si nikto nevšimne, že fronta rastie od piatka.

Zaznamenajte relay, transport, pravidlo firewallu a životnosť spolu. Tie štyri opisujú usporiadanie; ktorékoľvek z nich samo opisuje dohad.