Паштовая адпраўка не ўдаецца пры падключэнні VPN: вызначце этап

Таймаўт, памылка TLS і адказ 5xx адбываюцца на розных этапах. Класіфікуйце збой, пацвердзіце рэжым TLS порта, затым параўнайце шляхі, а не паролі.

Пошта, якая працавала ўсю раніцу, спыняецца ў момант, калі ўзнімаецца тунель, і першы інстынкт — перадрукаваць пароль. Гэты інстынкт прапускае больш карыснае пытанне: ці кліент наогул дасягнуў сервера і ці дайшоў ён дастаткова далёка, каб прапанаваць уліковыя даныя? Таймаўт, памылка сертыфіката і адказ з адмовай — тры розныя збоі, і толькі трэці датычыцца ўліковага запісу. Прайдзіце этапы па парадку, і 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, порт і рэжым не супадаюць. Выпраўце рэжым у кліенце замест адключэння праверкі сертыфіката, што ператварае памылку налады ў неправеранае злучэнне. Гэтае размежаванне дастаткова старое, каб быць стандартызаваным: неяўны TLS на порце 465 — гэта ўклад, апісаны ў 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, якія выкарыстоўвае кліент, шлях, які прайшло паведамленне, і адказ, які вярнуў сервер. Гэтыя чатыры факты ператвараюць расплывістую праблему выходных паведамленняў у змену, якую хтосьці можа разгледзець.

Падобныя артыкулы