Postfix, VPN ja smarthost: järjekord ei ole tulemüür

Kirjade järjekorras hoidmine, kuni VPN tõuseb, on planeerimisprobleem, ja tavaline lahendus on Postfix peatada, main.cf välja vahetada ja see uuesti käivitada. See töötab, ja see on vale kuju, sest segab kahte nõuet: millal tuleks kohaletoimetamist proovida ja milline võrgutee tohib seda kanda. Teine on tulemüüri otsus, ja ükski Postfixi direktiiv ei saa seda teha. Kui need kaks eraldada, on kummalgi väike ja testitav vastus.

Hoidke relay sihtkoht stabiilne, blokeerige otsene kohaletoimetamine võrgupiiril ja laske järjekorral oodata.

Kaks nõuet, mille inimesed üheks sulandavad

Relay ütleb Postfixile, kuhu kirjad üle anda; relayhost = [smtp.corp.example]:587 nimetab hosti ja pordi, kusjuures sulud suruvad selle järgmise hüppe jaoks maha MX-põhise valiku. Tee ütleb kernelile, kuhu pakettidel on lubatud minna. Õige relayhost ilma tee piiranguta laseb Postfixil ikkagi internetti otse jõuda, kui marsruutimistabel seda juhtub lubama, ja õige tulemüür vale relayhostiga saadab kirjad valesse kohta. Kumbki ei eelda teist.

Transpordikaardid, saatjapõhised ülekirjutused ja varurelayd väärivad kõik sama lugemist. Stabiilne relayhost ei ole tõestus, et iga seadistatud kohaletoimetamistee seda kasutab, ja relayst mööda minev varutee on sama tõrge paremas varjestuses.

Mida defer_transports tegelikult teeb

defer_transports hoiab sõnumeid nimetatud transportide jaoks kinni, nii et kohaletoimetamiskatset ei tehta enne, kui järjekorra jooks neid puudutab. See on planeerimiskontroll, ja järjekorra tühjendus kaalub selle üles; see on disain, mitte defekt. Kasutage master.cf-st pärit tegelikke transpordinimesid, sest kohandatud transport või eraldi nimetatud relay-transport ei ole kaetud ainult sellepärast, et selle programm räägib ka SMTP-d. Tavaline korduskatse on teine mehhanism: fail-closed tee korral kohaletoimetamiskatsed lihtsalt ebaõnnestuvad ja jäävad järjekorda, ilma et ükski edasilükkamisdirektiiv osaleks.

Püsivad tõrked ei oota viisakalt. Halb saaja või tagasilükatud volitus põrkab tagasi või jääb kõva veana kinni, selle asemel et oodata, kuni tunnel ilmub, nii et edasilükatud kirju täis järjekord ei ole automaatselt turvaline järjekord.

Nõudke teed võrgukihis

Piirang kuulub kohaliku väljundi piirile või isoleeritud võrguneimeruumi sisse. See peab katma relay tegelikud aadressid, transpordi ja pordi, sealhulgas IPv6, kui see on lubatud, sest TCP 25 blokeeriv reegel ei tee midagi relay jaoks pordil 587 või 465. Hoidke loopback ja kohalikud esitusvood eraldi, et järjekord ise edasi töötaks. Poliitika peaks jääma suletuks, kui tunnelitee kaob või ilmub uuesti mõne teise liidese nime all.

Liidese üles tuleku sündmus ei tõesta, et relay on selle kaudu kättesaadav. Sellepärast on konks, mis kontrollib linki ja seejärel järjekorra tühjendab, mugavus, mitte garantii: link võib kontrolli ja kohaletoimetamiskatse vahel muutuda.

Tõestage seda ühe kahjutu sõnumiga

Saatke üks kahjutu sõnum VPN-i maas olles, seejärel uurige postqueue -p väljundist edasilükkamise põhjust ja järjekorra ID-d. Taastage ettenähtud tee ja taotlege kontrollitud järjekorra jooksu, jälgides, kas sõnum lahkub relay kaudu, mitte kuskilt mujalt. Seejärel katkestage tee uuesti lennu ajal ja kinnitage, et sõnum naaseb järjekorda. Enne otsustamist, kui kaua katkestus võib kesta, vaadake üle maximal_queue_lifetime, sest nullväärtus tähendab ühte katset, mitte piiramatut säilitamist.

Jälgige järjekorra vanust ja kettaruumi kasutust. VPN-i ootav poliitika muutub kirjakatkestuseks, kui keegi ei märka, et järjekord on reedest saati kasvanud.

Kirjutage relay, transport, tulemüüri reegel ja eluiga koos üles. Need neli kirjeldavad korraldust; ükskõik milline neist üksi kirjeldab oletust.