Փոստի ուղարկումը ձախողվում է, երբ VPN-ը միանում է՝ գտեք փուլը

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

Փուլ 1. դասակարգեք ձախողումը նախքան հավատարմագրերին դիպչելը

Կարդացեք այն սխալը, որն իրականում արձակել է հավելվածը, ապա տեղադրեք այն երեք զամբյուղներից մեկում։ Ժամանակի սպառումը կամ կապի վերակայումը նշանակում է, որ TCP ուղին ձախողվել է, TLS կամ վկայագրի սխալը նշանակում է, որ ուղին աշխատել է, իսկ ձեռքսեղմումը՝ ոչ, կոդով SMTP պատասխանը նշանակում է, որ փոստային սերվերը պատասխանել է և որոշում կայացրել։ Յուրաքանչյուր զամբյուղ մատնանշում է տարբեր պատասխանատուի։

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

Կանգ առեք այստեղ, եթե չեք կարող ձախողումը վերարտադրել VPN-ից դուրս։ Մեկ մեքենայի վրա մեկ հավելվածում ի հայտ եկած խնդիրը դեռ ցանցային խնդիր չէ։

Փուլ 2. հաստատեք վերջնակետը և TLS ռեժիմը

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

openssl s_client -connect smtp.example.com:465 -servername smtp.example.com -quiet
openssl s_client -starttls smtp -connect smtp.example.com:587 -servername smtp.example.com -quiet
nc -vz smtp.example.com 587

Երկու ստուգումներից սխալը գործարկելը հենց այն սխալն է, որ անում է հաճախորդը, երբ կարգավորված է մյուս ռեժիմի համար։ Եթե իմպլիցիտ TLS ստուգումը կախվում է 587-ի վրա, կամ STARTTLS ստուգումը ձախողվում է 465-ի վրա, պորտն ու ռեժիմը չեն համընկնում։ Ուղղեք ռեժիմը հաճախորդում՝ վկայագրի ստուգումն անջատելու փոխարեն, ինչը կարգավորման սխալը վերածում է չստուգված կապի։ Այս բաժանումը բավական հին է, որպեսզի ստանդարտացված լինի՝ 465 պորտի իմպլիցիտ TLS-ը այն դասավորությունն է, որը նկարագրված է RFC 8314-ում։

Վկայագրի սխալն այստեղ տեղեկատվություն է, ոչ խոչընդոտ։ Այն անվանում է այն ինքնությունը, որը ներկայացրել է սերվերը, և այն ինքնությունը, որը սպասել է հաճախորդը, և երկուսն էլ կարելի է ուղղել առանց կապը թուլացնելու։

Փուլ 3. համեմատեք ուղիները՝ չփոխելով հաշիվը

Պահեք վերջնակետը, հաշիվը և հաճախորդի կարգավորումները հաստատուն և փոխեք միայն ուղին։ Ուղարկեք մեկ անգամ իջեցված թունելով և մեկ անգամ բարձրացվածով, և գրանցեք երթուղին և այն աղբյուրի հասցեն, որը կտեսնի սերվերը։ Եթե ձախողումը հետևում է ուղուն, դուք մեկուսացրել եք այն, եթե այն հետևում է մեքենային՝ ոչ։

ip route get smtp.example.com
curl -v --ssl-reqd --url smtp://smtp.example.com:587 --user "$SMTP_USER" \
  --mail-from [email protected] --mail-rcpt [email protected] --upload-file msg.txt

Լրիվ թունելը փոխում է այն աղբյուրի հասցեն, որը տեսնում է մատակարարը, և որոշ մատակարարներ անծանոթ աղբյուրի հետ վարվում են ավելի խստորեն, քան անծանոթ գաղտնաբառի։ Սա նրանց կողմի քաղաքականության որոշում է, և այն կարող է լինել մոխրագույն ցուցակ, արագության սահմանափակում կամ արգելափակում։ Մի ընդհանրացրեք մեկ մատակարարից բոլորի վրա և մի ենթադրեք, որ բացակայող NAT կանոնը բացատրում է յուրաքանչյուր ձախողում։ curl-ի արձանագրությունը ցույց է տալիս, թե որ փուլն է ձախողվել, նույնիսկ երբ հավելվածի սեփական մատյանը դա չի ցույց տալիս։

Եթե թունելը պետք է կրի ինտերնետ տրաֆիկ, ապա նրա երթուղավորումը և ելքի քաղաքականությունը երկուսն էլ պետք է թույլատրեն այս նպատակակետը։ Թունելը, որը կրում է միայն մասնավոր երթուղիներ, փոստային կապը թողնում է տեղական ուղու վրա, ինչը այլ համեմատություն է։

Փուլ 4. ուղարկեք մեկ անվնաս հաղորդագրություն և գրանցեք պատասխանը

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

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

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