Փոստը հասնում է սերվերին առանց VPN-ի. որտեղ կիրառել կանոնը

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

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

Ախտանիշը նման է Mac-ին, բայց արտահոսքը կարող է սերվերում լինել

Երբ փոստը համաժամեցվում է թունելից դուրս, սկսեք նրանից, ինչ սերվերն ընդունում է։ Եթե փոստի լսիչը պատասխանում է ինտերնետից եկող ուղիղ կապին, ապա հաճախորդի կողմի ոչ մի հարմարավետության կարգավորում չի փոխում այդ փաստը։ Mac-ը սովորական է վարվում դեռ բաց ծառայության նկատմամբ։

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

Այդ պատասխանը նաև ասում է՝ ծառայությունն ընդհանրապես կարո՞ղ է տարբերել VPN հաճախորդներին։ Եթե յուրաքանչյուր հաճախորդ գալիս է նույն պրոքսի հասցեով, աղբյուրի վրա հիմնված ընդունելությունը չի կարող նրանց բաժանել, և պահանջը պետք է տեղափոխվի նույնականացման կամ հաճախորդի կողմ։

Ընդունելություն սերվերում. մերժեք աղբյուրին, ոչ հավելվածին

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

Սա ամենաուժեղ սահմանն է, երբ պահանջն է «ծառայությունը չպետք է սպասարկի ուղիղ հաճախորդներին»։ Այն դիմանում է նույնիսկ երբ օգտատերը տեղադրում է այլ փոստային հաճախորդ, քանի որ մերժումը տեղի է ունենում նույնականացումից առաջ։ Այն նաև վերապրում է Mac-ին, որը անտեսում է իր VPN քաղաքականությունը։

Նրա սահմանը հավասարապես կարևոր է։ Մերժված կապը ապացուցում է, որ ծառայությունը մերժել է նստաշրջանը. այն չի ապացուցում, որ Mac-ը փորձ չի արել։ DNS լուծումը, TCP SYN-ը դեպի ավելի վաղ բեռնվածքի հավասարակշռիչ և վերափորձը ձախողումից հետո բոլորը կարող են տեղի ունենալ նախքան սերվերի կանոնին հասնելը։ Եթե պահանջը փորձերի բացահայտման մասին է, ոչ թե հասանելիության, ապա սերվերի ընդունելությունը վերահսկողության միայն կեսն է։

Կիրարկում հաճախորդում. արգելափակեք փորձը, ոչ միայն թունելը

Հաճախորդի կողմի կանոնը պետք է արգելի երթևեկությունը, ոչ թե պարզապես թունել սկսի փոստը բացելիս։ Փոստային տիրույթի համար ակտիվացման ձգանը կարող է VPN-ը բարձրացնել ճիշտ պահին, բայց այն չի սահմանում, թե ինչ է լինում, երբ թունելն անջատված է կամ ձախողվելուց հետո։

Օգտագործեք վերջնակետի արտադրանքի աջակցվող արգելափակման քաղաքականությունը և միտումնավոր սահմանազատեք դրա ծավալը։ Հավելվածի մակարդակի կանոնը ընդգրկում է այդ փոստային հավելվածի յուրաքանչյուր հաշիվ, ներառյալ անձնականը։ Նպատակակետի մակարդակի կանոնը պետք է անվանի աշխատանքային հաշվի IMAP-, ուղարկման և նույնականացման վերջնակետերը, և պետք է շարունակի աշխատել, երբ այդ հասցեները փոխվեն։

Ընդգրկեք հասցեների երկու ընտանիքները և գոյություն ունեցող նստաշրջանները։ Քաղաքականությունը, որը արգելափակում է նոր IPv4 կապերը, բայց անփոփոխ է թողնում IPv6-ը կամ հաստատված վարդակը, առաջացնում է ընդհատվող համաժամեցումներ, որոնք պատահական են թվում։ Ցանցային փոփոխությունները և քնի ցիկլերը նույն փորձարկման մասն են։

Հավելվածի և նպատակակետի մակարդակի կանոններն ունեն տարբեր ազդեցության ծավալ

Հավելվածի մակարդակի արգելափակումը հեշտ է մտածել. ոչ մի երթևեկություն Փոստից դուրս չի գալիս առանց թունելի։ Այն նաև կոպիտ է, քանի որ նույն հավելվածը կարող է պահել անձնական հաշիվ, որը ոչ մի կապ չունի քաղաքականության հետ։ Օգտատերերը դա նկատում են առաջինը և հաղորդում են որպես կոտրված փոստային հավելված։

Նպատակակետի մակարդակի արգելափակումն ավելի նեղ է և դժվար պահպանվող։ Այն պահանջում է հաշվի օգտագործած վերջնակետերի ամբողջական հավաքածուն, ներառյալ հայտնաբերման և նույնականացման ծառայությունները, և դրանք թարմացնելու գործընթաց։ Մեկը բաց թողնեք՝ հաշիվը կիսով է աշխատում. շատ ներառեք՝ անկապ փոստը կանգ է առնում։

Ընտրեք ըստ պահանջի ձևակերպման։ «Այս աշխատանքային հաշիվը չպետք է ուղիղ միանա» ցույց է տալիս նպատակակետի ծավալը։ «Այս Mac-ը չպետք է փոստ վարի VPN-ից դուրս» արդարացնում է ավելի լայն հավելվածի կանոնը, պայմանով որ սեփականատերը ընդունի անձնական հաշվի կողմնակի ազդեցությունը։

Փորձարկեք մերժումը և բացակայությունը առանձին

Առանձին փորձնական հաշվով միացեք VPN-ով և հաստատեք նորմալ աշխատանքը։ Ապա անջատվեք և փորձարկեք երկու անգամ. մեկ անգամ՝ տեսնելու՝ սերվերը մերժո՞ւմ է մուտքը, և մեկ անգամ՝ տեսնելու՝ Mac-ը ընդհանրապես կապ փորձո՞ւմ է։ Դրանք տարբեր դիտարկումներ են և պատկանում են տարբեր մատյանների։

Հետևեք հաճախորդի կողմի ապացույցներին SYN-ի կամ DNS հարցման համար, մինչ անջատված եք, և սերվերի մատյանին՝ մերժված կամ ընդունված նստաշրջանի համար։ Եթե սերվերը մերժում է, բայց հաճախորդը դեռ փորձում է, սերվերի կանոնը աշխատում է, և հաճախորդի կանոնը բացակայում է։ Եթե հաճախորդը փորձ չի անում, բայց սերվերը դեռ ընդունում է այլ հաճախորդների, սահմանը հենց այնտեղ է, որտեղ դուք դրել եք այն։

Գրանցեք կիրարկման սեփականատիրոջը, աղբյուրի հասցեն, որ սերվերն իրականում տեսնում է, և օգտագործված փորձնական հաշիվը։ Հաջորդ ցանցային կամ պրոքսի փոփոխությունը կարող է տեղափոխել այդ աղբյուրը, և դիտարկված արժեքը նշող գրառումն ավելի արագ է ստուգվում, քան գուշակության ևս մեկ փուլը։