Postfix, VPN ja smarthost: jono ei ole palomuuri

Postien pitäminen jonossa, kunnes VPN nousee, on aikatauluongelma, ja tavallinen ratkaisu on pysäyttää Postfix, vaihtaa main.cf ja käynnistää se uudelleen. Se toimii, ja se on väärä muoto, koska se sekoittaa kaksi vaatimusta: milloin toimitusta pitäisi yrittää ja mikä verkkoreitti saa sen kuljettaa. Toinen on palomuurin päätös, eikä mikään Postfixin direktiivi voi tehdä sitä. Kun ne kaksi erotetaan, kummallakin on pieni ja testattava vastaus.

Pidä relen kohde vakaana, estä suora toimitus verkkorajalla ja anna jonon hoitaa odotus.

Kaksi vaatimusta, jotka ihmiset sulauttavat yhdeksi

Relay kertoo Postfixille, mihin postit luovutetaan; relayhost = [smtp.corp.example]:587 nimeää isännän ja portin, ja hakasulkeet vaimentavat MX-perusteisen valinnan tuolle seuraavalle hypylle. Reitti kertoo ytimelle, minne paketit saavat mennä. Oikea relayhost ilman reittirajoitusta päästää Postfixin silti suoraan internetiin, kun reititystaulu sattuu sallimaan sen, ja oikea palomuuri väärällä relayhostilla lähettää postit väärään paikkaan. Kumpikaan ei edellytä toista.

Kuljetuskartat, lähettäjäkohtaiset ohitukset ja varareleet ansaitsevat kaikki saman luennan. Vakaa relayhost ei ole todiste siitä, että jokainen määritetty toimitusreitti käyttää sitä, ja relen ohittava varareitti on sama vika paremmassa naamioinnissa.

Mitä defer_transports oikeastaan tekee

defer_transports pidättelee viestejä nimettyjen kuljetusten osalta, joten toimitusta ei yritetä ennen kuin jonon kierros koskettaa niitä. Se on aikataulun ohjaus, ja jonon tyhjennys ohittaa sen; se on suunnittelua, ei vika. Käytä master.cf:n todellisia kuljetusnimiä, koska mukautettu kuljetus tai erikseen nimetty relay-kuljetus ei tule katetuksi vain siksi, että sen ohjelma puhuu myös SMTP:tä. Tavallinen uudelleenyritys on eri mekanismi: fail-closed-reitillä toimitusyritykset yksinkertaisesti epäonnistuvat ja jäävät jonoon ilman lykkäysdirektiiviä.

Pysyvät virheet eivät odota kohteliaasti. Huono vastaanottaja tai hylätty tunnistetieto palaa tai jää kovaksi virheeksi sen sijaan, että odottaisi tunnelin ilmestymistä, joten lykättyä postia täynnä oleva jono ei ole automaattisesti turvallinen jono.

Vaadi reitti verkkokerroksessa

Rajoitus kuuluu paikallisen lähdön rajalle tai eristettyyn verkkonimiavaruuteen. Sen on katettava relen todelliset osoitteet, kuljetus ja portti, mukaan lukien IPv6, jos se on käytössä, koska TCP 25:n estävä sääntö ei tee mitään portilla 587 tai 465 olevalle relelle. Pidä loopback ja paikalliset lähetysreitit erillään, jotta itse jono jatkaa toimintaansa. Käytännön pitäisi pysyä suljettuna, kun tunnelireitti katoaa tai ilmestyy uudelleen toisella liitännän nimellä.

Liitännän ylös-tapahtuma ei todista, että rele on sen kautta tavoitettavissa. Siksi koukku, joka tarkistaa linkin ja tyhjentää sitten jonon, on mukavuus eikä tae: linkki voi muuttua tarkistuksen ja toimitusyrityksen välillä.

Todista se yhdellä vaarattomalla viestillä

Lähetä yksi vaaraton viesti VPN:n ollessa alhaalla ja tutki sitten postqueue -p -tulosteesta lykkäyksen syy ja jonon ID. Palauta aiottu reitti ja pyydä valvottu jonon kierros ja katso, lähteekö viesti relen kautta eikä muualta. Katkaise sitten reitti uudelleen kesken lennon ja varmista, että viesti palaa jonoon. Tarkista maximal_queue_lifetime ennen kuin päätät, kuinka kauan katkos voi kestää, koska nolla-arvo tarkoittaa yhtä yritystä eikä rajatonta säilytystä.

Seuraa jonon ikää ja levyn käyttöä. VPN:ää odottava käytäntö muuttuu postikatkoksi, jos kukaan ei huomaa, että jono on kasvanut perjantaista lähtien.

Kirjaa rele, kuljetus, palomuurisääntö ja elinikä yhdessä. Ne neljä kuvaavat järjestelyn; mikä tahansa niistä yksin kuvaa arvauksen.