Бүкіл таң бойы жұмыс істеген пошта туннель көтерілген сәтте тоқтайды, ал бірінші инстинкт — құпия сөзді қайта теру. Бұл инстинкт неғұрлым пайдалы сұрақты өткізіп жібереді: клиент серверге мүлдем жетті ме және тіркелгі деректерін ұсынатындай алысқа барды ма? Тайм-аут, сертификат қатесі және бас тарту жауабы — үш түрлі ақау, тек үшіншісі ғана тіркелгіге қатысты. Кезеңдерді ретімен қарап шығыңыз, сонда 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 режимін, хабарлама жүрген жолды және сервер қайтарған жауапты атай алғанда толық болады. Осы төрт факт бұлыңғыр шығыс жәшігі мәселесін біреу қарай алатын өзгеріске айналдырады.

Қатысты мақалалар