Postfix, VPN en 'n smarthost: 'n waglys is nie 'n firewall nie

Om e-pos in die waglys te hou tot die VPN opkom, is 'n beplanningsprobleem, en die gewone oplossing is om Postfix te stop, main.cf te vervang en dit weer te begin. Dit werk, en dit is die verkeerde vorm, want dit meng twee vereistes: wanneer aflewering probeer moet word, en watter netwerkpad dit mag dra. Die tweede een is 'n firewall-besluit, en geen Postfix-richtlijn kan dit maak nie. Sodra die twee geskei is, het elkeen 'n klein en toetsbare antwoord.

Hou die relê-bestemming stabiel, blokkeer direkte aflewering by die netwerkgrens, en laat die waglys die wag doen.

Twee vereistes wat mense in een saamsmelt

Die relê sê vir Postfix waar om e-pos te oorhandig; relayhost = [smtp.corp.example]:587 noem 'n gasheer en poort, met hakies wat MX-gebaseerde keuse vir daardie volgende sprong onderdruk. Die pad sê vir die kernel waar pakkette mag gaan. 'n Korrekte relayhost sonder padbeperking laat Postfix steeds die internet direk bereik wanneer die roetebeplanner dit toevallig toelaat, en 'n korrekte firewall met 'n verkeerde relayhost stuur e-pos na die verkeerde plek. Nie een impliseer die ander nie.

Vervoerkaarte, oorheersings per afsender en terugval-relêe verdien elkeen dieselfde lesing. 'n Stabiele relayhost is nie bewys dat elke gekonfigureerde afleweringsroete dit gebruik nie, en 'n terugval wat die relê omseil, is dieselfde fout met beter kamoeflering.

Wat defer_transports werklik doen

defer_transports hou boodskappe vir die genoemde vervoerders vas, sodat geen afleweringspoging gedoen word voordat 'n waglysloop hulle raak nie. Dit is 'n beplanningsbeheer, en 'n waglys-flush oorheers dit; dit is die ontwerp, nie 'n fout nie. Gebruik die werklike vervoernames uit master.cf, want 'n pasgemaakte vervoerder of 'n afsonderlik genoemde relê-vervoerder word nie gedek net omdat sy program ook SMTP praat nie. Gewone herprobeer is 'n ander meganisme: met 'n fail-closed pad misluk afleweringspogings bloot en bly in die waglys, sonder enige uitstelningsrichtlijn.

Permanente foute wag nie beleefd nie. 'n Slegte ontvanger of 'n verwerpte geloofsbrief bons of staan as 'n harde fout vas in plaas daarvan om te sit tot die tonnel verskyn, so 'n waglys vol uitgestelde e-pos is nie outomaties 'n veilige waglys nie.

Dwing die pad op die netwerklaag af

Die beperking hoort by die plaaslike uitsetgrens of binne 'n geïsoleerde netwerk-naamruimte. Dit moet die relê se werklike adresse, vervoer en poort dek, insluitend IPv6 indien geaktiveer, want 'n reël wat TCP 25 blokkeer, doen niks vir 'n relê op 587 of 465 nie. Hou loopback en plaaslike indieningspaaie apart sodat die waglys self bly werk. Die beleid moet gesluit bly wanneer die tonnelroete verdwyn of onder 'n ander koppelvlaknaam weer verskyn.

'n Koppelvlak-op-gebeurtenis bewys nie dat die relê daardeur bereikbaar is nie. Daarom is 'n haak wat die skakel nagaan en dan spoel, 'n gerief eerder as 'n waarborg: die skakel kan verander tussen die nagaan en die afleweringspoging.

Bewys dit met een skadelose boodskap

Stuur een skadelose boodskap met die VPN af, en ondersoek dan postqueue -p vir die uitgestelde rede en die waglys-ID. Herstel die beoogde pad en versoek 'n beheerde waglysloop, en kyk of die boodskap deur die relê vertrek eerder as iewers anders. Breek dan die pad weer midde-in die vlug en bevestig dat die boodskap na die waglys terugkeer. Hersien maximal_queue_lifetime voordat jy besluit hoe lank 'n onderbreking mag duur, want 'n waarde van nul beteken een poging eerder as onbeperkte behoud.

Monitor waglysouderdom en skyfgebruik. 'n Beleid wat vir die VPN wag, word 'n e-posonderbreking as niemand agterkom die waglys groei sedert Vrydag nie.

Teken die relê, die vervoer, die firewall-reël en die leeftyd saam aan. Daardie vier beskryf die reëling; enige een alleen beskryf 'n raaiskoot.