Postfix, VPN dhe një smarthost: radha nuk është firewall

Mbajtja e postës në radhë derisa të ngrihet VPN është problem planifikimi, dhe zgjidhja e zakonshme është ndalimi i Postfix, zëvendësimi i main.cf dhe nisja përsëri. Kjo funksionon, dhe është forma e gabuar, sepse përzien dy kërkesa: kur duhet provuar dërgimi dhe cila rrugë rrjeti mund ta mbajë atë. E dyta është vendim i firewall-it, dhe asnjë direktivë e Postfix nuk mund ta marrë. Pasi ndahen të dyja, secila ka një përgjigje të vogël dhe të testueshme.

Mbajeni destinacionin e relay-t të qëndrueshëm, bllokoni dërgimin direkt në kufirin e rrjetit dhe lëreni radhën të bëjë pritjen.

Dy kërkesa që njerëzit i bashkojnë në një

Relay i thotë Postfix ku ta dorëzojë postën; relayhost = [smtp.corp.example]:587 emërton një host dhe një port, ndërsa kllapat shtypin zgjedhjen bazuar në MX për atë hop tjetër. Rruga i thotë kernelit ku lejohet të shkojnë paketat. Një relayhost i saktë pa kufizim rruge ende lejon Postfix të arrijë internetin drejtpërdrejt kur tabela e rrugëtimit e lejon, dhe një firewall i saktë me relayhost të gabuar e dërgon postën në vendin e gabuar. Asnjëra nuk nënkupton tjetrën.

Hartat e transportit, zëvendësimet për dërgues dhe relay-t rezervë secili meriton të njëjtin lexim. Një relayhost i qëndrueshëm nuk është provë që çdo rrugë dërgimi e konfiguruar e përdor atë, dhe një rrugë rezervë që anashkalon relay-n është i njëjti dështim me kamuflazh më të mirë.

Çfarë bën në të vërtetë defer_transports

defer_transports mban mesazhet për transportet e emërtuara, kështu që asnjë përpjekje dërgimi nuk bëhet derisa një kalim i radhës t'i prekë ato. Është kontroll planifikimi, dhe zbrazja e radhës e anulon atë; ky është dizajni dhe jo defekt. Përdorni emrat e vërtetë të transportit nga master.cf, sepse një transport i personalizuar ose një transport relay i emërtuar veçmas nuk mbulohet vetëm sepse programi i tij flet edhe SMTP. Përpjekja e zakonshme e përsëritjes është mekanizëm tjetër: me një rrugë fail-closed, përpjekjet e dërgimit thjesht dështojnë dhe mbeten në radhë, pa asnjë direktivë shtyrjeje.

Dështimet e përhershme nuk presin me mirësjellje. Një marrës i keq ose një kredencial i refuzuar kthehet ose ngec si gabim i fortë në vend që të rrijë derisa të shfaqet tuneli, prandaj një radhë plot postë të shtyrë nuk është automatikisht radhë e sigurt.

Impononi rrugën në shtresën e rrjetit

Kufizimi i përket kufirit të daljes lokale ose brenda një hapësire emrash rrjeti të izoluar. Duhet të mbulojë adresat reale të relay-t, transportin dhe portin, duke përfshirë IPv6 nëse është aktivizuar, sepse një rregull që bllokon TCP 25 nuk bën asgjë për një relay në 587 ose 465. Mbajini loopback dhe rrugët lokale të dorëzimit të ndara që radha vetë të vazhdojë të punojë. Politika duhet të mbetet e mbyllur kur rruga e tunelit zhduket ose rishfaqet nën një emër tjetër ndërfaqeje.

Ngjarja e ngritjes së ndërfaqes nuk provon që relay është i arritshëm përmes saj. Prandaj një grep që kontrollon lidhjen dhe pastaj zbraz radhën është lehtësi dhe jo garanci: lidhja mund të ndryshojë midis kontrollit dhe përpjekjes së dërgimit.

Provoseni me një mesazh të padëmshëm

Dërgoni një mesazh të padëmshëm me VPN poshtë, pastaj inspektoni postqueue -p për arsyen e shtyrjes dhe ID-në e radhës. Riktheni rrugën e synuar dhe kërkoni një kalim të kontrolluar të radhës, duke vëzhguar nëse mesazhi del përmes relay-t dhe jo diku tjetër. Pastaj thyeni përsëri rrugën në mes të fluturimit dhe konfirmoni që mesazhi kthehet në radhë. Rishikoni maximal_queue_lifetime përpara se të vendosni sa mund të zgjasë një ndërprerje, sepse vlera zero nënkupton një përpjekje dhe jo mbajtje të pakufizuar.

Monitoroni moshën e radhës dhe përdorimin e diskut. Një politikë që pret VPN bëhet ndërprerje poste nëse askush nuk vëren se radha po rritet që nga e Premtja.

Regjistroni së bashku relay-n, transportin, rregullin e firewall-it dhe jetëgjatësinë. Ato katër përshkruajnë rregullimin; secili prej tyre vetëm përshkruan një hamendje.