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-ийн дүрэм, ашиглалтын хугацааг хамт бичээрэй. Тэр дөрөв нь зохион байгуулалтыг дүрсэлдэг; тэдгээрийн аль нэг нь дангаараа таамаглалыг дүрсэлдэг.