Postfix, VPN eta smarthost bat: ilara ez da suebaki bat

Posta ilaran edukitzea VPN-a altxatu arte plangintza arazoa da, eta ohiko irtenbidea Postfix gelditzea, main.cf aldatzea eta berriro abiaraztea da. Horrek funtzionatzen du, eta okerreko forma da, bi baldintza nahasten baititu: noiz saiatu behar den bidalketa eta zein sare-bidek eraman dezakeen. Bigarrena suebakiaren erabakia da, eta Postfixen direktiba batek ere ezin du hartu. Biak bereizi ondoren, bakoitzak erantzun txiki eta frogagarria du.

Mantendu errelearen helmuga egonkor, blokeatu bidalketa zuzena sare-mugan, eta utzi ilarari itxarotea egiten.

Jendeak bakarrean batu ohi dituen bi baldintza

Erreleak Postfixi esaten dio non eman posta; relayhost = [smtp.corp.example]:587 ostalari bat eta portu bat izendatzen ditu, eta kortxeteek hurrengo jauzi horretarako MX oinarritutako hautaketa kentzen dute. Bideak kernelari esaten dio nora joan daitezkeen paketeak. Bide-murrizketarik gabeko relayhost zuzen batek Postfix zuzenean internetera iristen uzten du oraindik bideratze-taulak hori baimentzen duenean, eta suebaki zuzen batek relayhost okerrarekin posta toki okerrean uzten du. Batak ez du bestea inplikatzen.

Garraio-mapak, igorle bakarrerako gainidazketak eta ordezko erreleek irakurketa bera merezi dute. relayhost egonkorra ez da froga konfiguratutako bidalketa-bide guztiek hura erabiltzen dutenik, eta errelea saihesten duen ordezko bide bat hutsegite bera da kamuflaje hobearekin.

Zer egiten du defer_transports-ek benetan

defer_transports izendatutako garraioetarako mezuak atxikitzen ditu, beraz ez da bidalketa-saiakuntzarik egiten ilararen pase batek ukitzen dituen arte. Plangintza-kontrola da, eta ilararen hustuketak gainditzen du; hori da diseinua, ez akatsa. Erabili master.cf fitxategiko garraio-izen errealak, garraio pertsonalizatu bat edo bereiz izendatutako relay garraio bat ez baitago estalita bere programak SMTP ere hitz egiten duelako bakarrik. Ohiko berriz saiakera beste mekanismo bat da: fail-closed bide batekin, bidalketa-saiakerak huts egiten du besterik gabe eta ilaran geratzen da, atzerapen-direktibarik gabe.

Hutsegite iraunkorrek ez dute adeitsu itxaroten. Hartzaile txar batek edo ukatutako kredentzial batek itzuli egiten du edo errore gogor gisa itsasten da tunela agertu arte itxaron beharrean, beraz atzeratutako postaz betetako ilara ez da automatikoki ilara segurua.

Behartu bidea sare-geruzan

Murrizketa irteera lokalaren mugan edo sare-namespace isolatu baten barruan dagokio. Errelearen helbide errealak, garraioa eta portua estali behar ditu, IPv6 ere bai gaituta badago, TCP 25 blokeatzen duen arauak ezer ez baitu egiten 587 edo 465 portuko errele batentzat. Eutsi loopback eta bidalketa lokaleko bideak bereizita, ilarak berak funtzionatzen jarrai dezan. Politikak itxita jarraitu beharko luke tuneleko bideak desagertzen denean edo interfaze-izen ezberdin baten pean berriro agertzen denean.

Interfazearen goratze-gertaerak ez du frogatzen errelea haren bidez irisgarria denik. Horregatik, esteka egiaztatu eta gero ilara husten duen hook bat erosotasuna da, ez bermea: esteka alda daiteke egiaztapenaren eta bidalketa-saiakeren artean.

Froga ezazu mezu kaltegabe batekin

Bidali mezu kaltegabe bat VPN-a behera dagoela, eta gero aztertu postqueue -p atzerapenaren arrazoia eta ilararen IDa lortzeko. Berrezarri nahi den bidea eta eskatu ilararen pase kontrolatu bat, mezua erreletik ateratzen den ala beste nonbaitetik ikusiz. Gero hautsi bidea berriro hegaldiaren erdian eta berretsi mezua ilarara itzultzen dela. Berrikusi maximal_queue_lifetime etenaldi batek zenbat iraun dezakeen erabaki aurretik, zero balioak saiakera bat esan nahi baitu, ez atxikipen mugagabea.

Ikuskatu ilararen adina eta disko-erabilera. VPN-aren zain dagoen politika posta-etenaldi bihurtzen da inork ostiraletik ilara hazten ari dela nabaritzen ez badu.

Erregistratu errelea, garraioa, suebakiaren araua eta bizitza dena batera. Lau horiek antolaketa deskribatzen dute; horietako edozein bakarrik susmo bat deskribatzen du.