Postfix, VPN og smarthost: biðröð er ekki eldveggur

Að halda pósti í biðröð þar til VPN kemur upp er tímasetningarvandamál, og venjulega lausnin er að stöðva Postfix, skipta um main.cf og ræsa það aftur. Það virkar, og það er rangt form, því það blandar tveimur kröfum: hvenær eigi að reyna sendingu, og hvaða netleið megi bera hana. Sú seinni er ákvörðun eldveggjar, og engin Postfix-tilskipun getur tekið hana. Þegar þessum tveimur er skipt, hefur hvor um sig litla og prófanlega svörun.

Haltu áfangastað relésins stöðugum, lokaðu fyrir beina sendingu á netmörkum og láttu biðröðina sjá um biðina.

Tvær kröfur sem fólk bræðir saman í eina

Reléið segir Postfix hvert póstinum skuli skilað; relayhost = [smtp.corp.example]:587 nefnir hýsil og port, og svigar bæla MX-byggt val fyrir næsta hopp. Leiðin segir kjarnanum hvert pakkarnir mega fara. Rétt relayhost án leiðartakmörkunar leyfir Postfix samt að ná beint á internetið þegar leiðartöflurnar leyfa það, og réttur eldveggur með röngu relayhost sendir póst á rangann stað. Hvorugt felur í sér hitt.

Flutningskort, yfirskriftir eftir sendanda og vararelé eiga öll sama lestur skilið. Stöðugt relayhost er ekki sönnun þess að öll uppsett sendingarleið noti það, og varaleið sem fer fram hjá reléinu er sama bilun í betri dulargervi.

Hvað defer_transports gerir í raun

defer_transports heldur skilaboðum fyrir tilgreindar flutningstegundir þannig að engin sendingartilraun er gerð fyrr en biðraðarhringur snertir þær. Það er tímasetningarstýring, og tæming biðraðar gengur yfir hana; það er hönnunin en ekki galli. Notaðu raunveruleg flutningsheiti úr master.cf, því sérsniðinn flutningur eða sérnefndur reléflutningur er ekki innifalinn bara af því að forritið hans talar líka SMTP. Venjuleg endurtilraun er annar gangverkur: með fail-closed leið mistakast sendingartilraunir einfaldlega og sitja eftir í biðröðinni, án nokkurrar frestunartilskipunar.

Varanlegar bilanir bíða ekki kurteislega. Lélegur viðtakandi eða hafnað auðkenni skoppar eða situr eftir sem harða villa í stað þess að bíða þar til göngin birtast, svo biðröð full af frestuðum pósti er ekki sjálfkrafa örugg biðröð.

Þvingaðu leiðina á netlaginu

Takmörkunin á heima á mörkum staðbundinnar úttaks eða inni í einangruðu netnafnrými. Hún verður að ná yfir raunveruleg heimilisföng relésins, flutning og port, þar með talin IPv6 ef það er virkt, því regla sem lokar TCP 25 gerir ekkert fyrir relé á 587 eða 465. Haltu loopback og staðbundnum sendingarleiðum aðskildum svo biðröðin sjálf haldi áfram að virka. Stefnunni ætti að halda lokaðri þegar leið gönganna hverfur eða birtist aftur undir öðru viðmótsheiti.

Atburður þar sem viðmót fer upp sannar ekki að reléið sé aðgengilegt í gegnum það. Þess vegna er krókur sem athugar tenginguna og tæmir svo biðröðina þægindi fremur en ábyrgð: tengingin getur breyst milli athugunar og sendingartilraunar.

Sannaðu það með einu hættulausu skilaboði

Sendu eitt hættulaust skilaboð með VPN niðri, og skoðaðu svo postqueue -p fyrir ástæðu frestunar og auðkenni biðraðar. Endurheimtu fyrirhugaðu leiðina og biddu um stýrðan biðraðarhring, og fylgstu með hvort skilaboðin fari út í gegnum reléið frekar en eitthvert annað. Rjúfðu svo leiðina aftur í miðri ferð og staðfestu að skilaboðin snúi aftur í biðröðina. Farðu yfir maximal_queue_lifetime áður en þú ákveður hve lengi bilun má standa, því núllgildi þýðir eina tilraun en ekki ótakmarkaða varðveislu.

Fylgstu með aldri biðraðar og diskanotkun. Stefna sem bíður VPN breytist í póstbilun ef enginn tekur eftir að biðröðin hefur stækkað frá föstudegi.

Skráðu reléið, flutninginn, eldveggsregluna og líftímann saman. Þau fjögur lýsa fyrirkomulaginu; hvert þeirra eitt og sér lýsir ágiskun.