Postfix, VPN жана smarthost: кезек firewall эмес

VPN көтөрүлгөнгө чейин почтаны кезекте кармоо — пландоо маселеси, ал эми адаттагы чечим Postfix-ти токтотуп, main.cf-ти алмаштырып, кайра иштетүү. Бул иштейт, бирок бул туура эмес форма, анткени эки талапты аралаштырат: жеткирүүнү качан сынап көрүү керек жана кайсы тармак жолу аны ташый алат. Экинчиси — firewall чечими, аны эч бир Postfix директивасы кабыл ала албайт. Экөө бөлүнгөндө, ар биринин кичине жана текшерилүүчү жообу бар.

Риллейдин багытын туруктуу кармаңыз, тармак чегинде түз жеткирүүнү бөгөттөңүз жана күтүүнү кезекке калтырыңыз.

Адамдар бириктирген эки талап

Риллей Postfix-ке почтаны кайда өткөрүүнү айтат; relayhost = [smtp.corp.example]:587 хост жана портту атайт, ал эми кашаалар кийинки секирик үчүн MX негизиндеги тандоону басат. Жол ядрого пакеттер кайда бара аларын айтат. Жол чектөөсүз туура relayhost маршруттоо таблицасы уруксат бергенде Postfix-тин интернетке түз чыгышына дагы жол берет, ал эми туура эмес relayhost менен туура firewall почтаны туура эмес жерге жөнөтөт. Эч бири экинчисин билдирбейт.

Транспорт карталары, жөнөтүүчү боюнча кайра аныктоолор жана камдык риллейлер ар бири ошол эле окууга татыктуу. Туруктуу relayhost конфигурацияланган ар бир жеткирүү жолу аны колдонорунун далили эмес, ал эми риллейди айланып өткөн камдык жол — жакшыраак жасалма бет каптагы ошол эле бузукулук.

defer_transports чындыгында эмне кылат

defer_transports аталган транспорттор үчүн билдирүүлөрдү кармап турат, ошондуктан кезек айланышы аларга тиймейинче жеткирүү аракети жасалбайт. Бул пландоо көзөмөлү, ал эми кезекти бошотуу аны басып озат; бул дизайн, кемчилик эмес. master.cf боюнча чыныгы транспорт аттарын колдонуңуз, анткени ыңгайлаштырылган транспорт же өзүнчө аталган риллей транспорту анын программасы SMTP да сүйлөгөндүгүнөн улам гана камтылбайт. Жөнөкөй кайталоо — башка механизм: fail-closed жол менен жеткирүү аракеттери жөн гана ишке ашпайт жана кезекте калат, эч кандай кечиктирүү директивасы катышпайт.

Туруктуу бузулуулар сылык күтпөйт. Жаман алуучу же четке кагылган купуя маалымат туннель пайда болгонго чейин отуруунун ордуна кайтарылат же катуу ката катары илинип калат, ошондуктан кечиктирилген почтага толгон кезек автоматтык түрдө коопсуз кезек эмес.

Жолду тармак катмарында милдеттендириңиз

Чектөө жергиликтүү чыгуу чегине же обочолонгон тармактык аттар мейкиндигине таандык. Ал риллейдин чыныгы даректерин, транспортун жана портун камтышы керек, кошулган болсо IPv6-ны да, анткени TCP 25-ти бөгөттөгөн эреже 587 же 465 портундагы риллей үчүн эч нерсе кылбайт. Loopback жана жергиликтүү жөнөтүү жолдорун өзүнчө кармаңыз, кезек өзү ишин улантсын. Туннель жолу жоголгондо же башка интерфейс аты менен кайра пайда болгондо саясат жабык бойдон калышы керек.

Интерфейстин көтөрүлүү окуясы риллейдин анын аркылуу жеткиликтүү экенин далилдебейт. Ошондуктан байланышты текшерип, анан кезекти бошото турган илгич — кепилдик эмес, ыңгайлуулук: байланыш текшерүү менен жеткирүү аракетинин ортосунда өзгөрүшү мүмкүн.

Бир зыянсыз билдирүү менен далилдеңиз

VPN өчүк кезде бир зыянсыз билдирүү жөнөтүңүз, анан кечиктирүү себеби жана кезек ID-си үчүн postqueue -p текшериңиз. Көздөлгөн жолду калыбына келтирип, көзөмөлдөнгөн кезек айланышын сураңыз, билдирүү башка жерге эмес, риллей аркылуу чыгарын байкаңыз. Анан учуу ортосунда жолду кайра үзүп, билдирүүнүн кезекке кайтарын ырастаңыз. Үзгүлтүк канчага созулаарын чечээрден мурун maximal_queue_lifetime-ти карап чыгыңыз, анткени нөл мааниси чексиз сактоо эмес, бир аракетти билдирет.

Кезектин жашын жана дисктин колдонулушун көзөмөлдөңүз. VPN-ти күткөн саясат, эгер кимдир бирөө кезектин жумадан бери өсүп жатканын байкабаса, почта үзгүлтүгүнө айланат.

Риллейди, транспортту, firewall эрежесин жана жашоо мөөнөтүн бирге жазыңыз. Ошол төртөө жайгашууну сүрөттөйт; алардын кайсынысы болбосун жалгыз өзү божомолду сүрөттөйт.