Postfix, VPN և smarthost. հերթը ֆայրվոլ չէ

Փոստը հերթում պահելը մինչև VPN-ի բարձրանալը ժամանակացույցի խնդիր է, և սովորական լուծումը Postfix-ը կանգնեցնելն է, main.cf-ը փոխելը և նորից գործարկելը։ Դա աշխատում է, և դա սխալ ձև է, որովհետև խառնում է երկու պահանջ՝ երբ պետք է փորձել առաքումը, և որ ցանցային ուղին կարող է տանել այն։ Երկրորդը ֆայրվոլի որոշում է, և ոչ մի Postfix հրահանգ չի կարող այն կայացնել։ Երբ երկուսը բաժանվեն, յուրաքանչյուրն ունի փոքր և ստուգելի պատասխան։

Պահեք ռելեյի նպատակակետը կայուն, արգելափակեք ուղղակի առաքումը ցանցի սահմանին, և թողեք հերթը սպասի։

Երկու պահանջ, որ մարդիկ միավորում են մեկի մեջ

Ռելեյը Postfix-ին ասում է, թե որտեղ հանձնել փոստը. relayhost = [smtp.corp.example]:587-ը նշում է հոսթ և պորտ, իսկ փակագծերը ճնշում են MX-ի վրա հիմնված ընտրությունը այդ հաջորդ թռիչքի համար։ Ուղին միջուկին ասում է, թե որտեղ կարող են գնալ փաթեթները։ Ճիշտ relayhost առանց ուղու սահմանափակման դեռ թույլ է տալիս Postfix-ին ուղղակիորեն հասնել ինտերնետ, երբ երթուղային աղյուսակը դա թույլ է տալիս, և ճիշտ ֆայրվոլ սխալ relayhost-ով փոստն ուղարկում է սխալ տեղ։ Ոչ մեկը չի ենթադրում մյուսը։

Տրանսպորտային քարտեզները, ուղարկողով պայմանավորված փոխարինումները և պահուստային ռելեյները արժանի են նույն ընթերցմանը։ Կայուն relayhost-ը ապացույց չէ, որ յուրաքանչյուր կարգավորված առաքման ուղի օգտագործում է այն, և ռելեյը շրջանցող պահուստային ուղին նույն խափանումն է ավելի լավ դիմակով։

Ինչ է իրականում անում defer_transports-ը

defer_transports-ը պահում է հաղորդագրությունները նշված տրանսպորտների համար, այնպես որ առաքման փորձ չի արվում, քանի դեռ հերթի մի շրջան չի դիպչել նրանց։ Դա ժամանակացույցի կառավարում է, և հերթի թափումը գերազանցում է այն. դա նախագիծ է, ոչ թերություն։ Օգտագործեք master.cf-ի իրական տրանսպորտի անունները, քանի որ հատուկ տրանսպորտը կամ առանձին անվանված ռելեյ-տրանսպորտը չի ընդգրկվում միայն այն պատճառով, որ նրա ծրագիրը նաև խոսում է SMTP։ Սովորական կրկնափորձը այլ մեխանիզմ է. fail-closed ուղու դեպքում առաքման փորձերը պարզապես ձախողվում են և մնում հերթում, առանց հետաձգման հրահանգի։

Մշտական խափանումները քաղաքավարի չեն սպասում։ Վատ ստացողը կամ մերժված հավատարմագրությունը վերադառնում է կամ կպչում է որպես կոշտ սխալ՝ թունելի հայտնվելուն սպասելու փոխարեն, ուստի հետաձգված փոստով լի հերթը ինքնաբերաբար անվտանգ հերթ չէ։

Պարտադրեք ուղին ցանցային շերտում

Սահմանափակումը պատկանում է տեղական ելքի սահմանին կամ մեկուսացված ցանցային անվանատարածքի ներսում։ Այն պետք է ընդգրկի ռելեյի իրական հասցեները, տրանսպորտը և պորտը, ներառյալ IPv6-ը, եթե միացված է, որովհետև TCP 25-ը արգելափակող կանոնը ոչինչ չի անում 587-ի կամ 465-ի ռելեյի համար։ Առանձին պահեք loopback-ը և տեղական ուղարկման ուղիները, որպեսզի հերթն ինքը շարունակի աշխատել։ Քաղաքականությունը պետք է փակ մնա, երբ թունելի ուղին անհետանում է կամ նորից հայտնվում մեկ այլ ինտերֆեյսի անունով։

Ինտերֆեյսի բարձրանալու իրադարձությունը չի ապացուցում, որ ռելեյը հասանելի է դրա միջով։ Այդ պատճառով կապը ստուգող և ապա հերթը թափող կեռիկը հարմարավետություն է, ոչ երաշխիք. կապը կարող է փոխվել ստուգման և առաքման փորձի միջև։

Ապացուցեք մեկ անվնաս հաղորդագրությամբ

Ուղարկեք մեկ անվնաս հաղորդագրություն VPN-ը անջատված վիճակում, ապա ստուգեք postqueue -p-ը հետաձգման պատճառի և հերթի ID-ի համար։ Վերականգնեք նախատեսված ուղին և պահանջեք վերահսկվող հերթի շրջան՝ հետևելով, թե արդյոք հաղորդագրությունը դուրս է գալիս ռելեյով, այլ ոչ այլ տեղ։ Ապա նորից կտրեք ուղին թռիչքի կեսին և հաստատեք, որ հաղորդագրությունը վերադառնում է հերթ։ Նախքան որոշելը, թե որքան կարող է տևել ընդհատումը, վերանայեք maximal_queue_lifetime-ը, որովհետև զրո արժեքը նշանակում է մեկ փորձ, ոչ անսահմանափակ պահում։

Հետևեք հերթի տարիքին և սկավառակի օգտագործմանը։ VPN-ին սպասող քաղաքականությունը վերածվում է փոստի ընդհատման, եթե ոչ ոք չի նկատում, որ հերթը աճում է ուրբաթից։

Գրանցեք ռելեյը, տրանսպորտը, ֆայրվոլի կանոնը և կյանքի տևողությունը միասին։ Այդ չորսը նկարագրում են դասավորությունը. նրանցից ցանկացածը առանձին նկարագրում է ենթադրություն։