Postfix, VPN kaj smarthost: vico ne estas fajroŝirmilo

Teni retpoŝton en vico ĝis la VPN ekfunkcias estas planada problemo, kaj la kutima solvo estas haltigi Postfix, anstataŭigi main.cf kaj restarti ĝin. Tio funkcias, kaj ĝi estas la malĝusta formo, ĉar ĝi miksas du postulojn: kiam oni provu liveradon, kaj kiu reta vojo rajtas porti ĝin. La dua estas decido de fajroŝirmilo, kaj neniu Postfix-direktivo povas fari ĝin. Post kiam la du disiĝas, ĉiu havas malgrandan kaj testeblan respondon.

Tenu la celon de la relajso stabila, bloku rektan liveradon ĉe la reta limo, kaj lasu la vicon fari la atendadon.

Du postuloj, kiujn homoj kunfandas en unu

La relajso diras al Postfix, kien doni la retpoŝton; relayhost = [smtp.corp.example]:587 nomas gastiganton kaj pordon, kaj krampoj subpremas la elekton bazitan sur MX por tiu sekva salto. La vojo diras al la kerno, kien la pakaĵoj rajtas iri. Korekta relayhost sen voja limigo ankoraŭ lasas Postfix atingi la interreton rekte kiam la enkursiga tabelo hazarde permesas tion, kaj korekta fajroŝirmilo kun malĝusta relayhost sendas retpoŝton al la malĝusta loko. Neniu implicas la alian.

Transportmapoj, anstataŭigoj laŭ sendanto kaj rezervaj relajsoj ĉiu meritas la saman legadon. Stabila relayhost ne estas pruvo, ke ĉiu agordita livera vojo uzas ĝin, kaj rezerva vojo, kiu preteriras la relajson, estas la sama fiasko en pli bona kamuflaĵo.

Kion defer_transports efektive faras

defer_transports retenas mesaĝojn por la nomitaj transportoj, do neniu liverprovo estas farata ĝis vica trairo tuŝas ilin. Ĝi estas planada kontrolo, kaj vica malplenigo superas ĝin; tio estas la dezajno, ne difekto. Uzu la verajn transportnomojn el master.cf, ĉar propra transporto aŭ aparte nomita relajsa transporto ne estas kovrita nur ĉar ĝia programo ankaŭ parolas SMTP. Ordinara ripeto estas alia mekanismo: kun fail-closed vojo, liverprovoj simple malsukcesas kaj restas en la vico, sen ia prokrasta direktivo.

Permanentaj fiaskoj ne atendas ĝentile. Malbona ricevanto aŭ rifuzita legitimilo resaltas aŭ restas kiel malmola eraro anstataŭ sidi ĝis la tunelo aperas, do vico plena de prokrastita retpoŝto ne estas aŭtomate sekura vico.

Devigu la vojon ĉe la reta tavolo

La limigo apartenas al la limo de loka eligo aŭ ene de izolita reta nomspaco. Ĝi devas kovri la realajn adresojn de la relajso, la transporton kaj la pordon, inkluzive IPv6 se ebligita, ĉar regulo blokanta TCP 25 faras nenion por relajso ĉe 587 aŭ 465. Tenu loopback kaj lokajn sendovojojn aparte, por ke la vico mem daŭre funkciu. La politiko devus resti fermita kiam la tunela vojo malaperas aŭ reaperas sub alia interfaca nomo.

Okazaĵo de interfaca ekfunkcio ne pruvas, ke la relajso estas atingebla tra ĝi. Tial hoko, kiu kontrolas la ligon kaj poste malplenigas la vicon, estas oportuneco prefere ol garantio: la ligo povas ŝanĝiĝi inter la kontrolo kaj la liverprovo.

Pruvu ĝin per unu sendanĝera mesaĝo

Sendu unu sendanĝeran mesaĝon kun la VPN mallevita, poste inspektu postqueue -p por la prokrasta kialo kaj la vica ID. Restarigu la celitan vojon kaj petu kontrolitan vican trairon, observante ĉu la mesaĝo foriras tra la relajso anstataŭ aliloke. Poste rompu la vojon denove dumfluge kaj konfirmu, ke la mesaĝo revenas al la vico. Reviziu maximal_queue_lifetime antaŭ ol decidi kiom longe paneo rajtas daŭri, ĉar nula valoro signifas unu provon anstataŭ senlima konservado.

Monitoru la aĝon de la vico kaj diskuzon. Politiko, kiu atendas la VPN, fariĝas retpoŝta paneo se neniu rimarkas, ke la vico kreskas ekde vendredo.

Registru la relajson, la transporton, la fajroŝirmilan regulon kaj la vivodaŭron kune. Tiuj kvar priskribas la aranĝon; iu ajn el ili sola priskribas konjekton.