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 режимин, билдирүү баскан жолду жана сервер кайтарган жоопту атай алганыңызда толук болот. Ошол төрт факт бүдөмүк чыккан кутуча маселесин бирөө карай ала турган өзгөртүүгө айландырат.