Испраќањето пошта не успева кога 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, портата и режимот не се совпаѓаат. Поправете го режимот во клиентот наместо да го исклучите проверувањето на сертификатот, што конфигурациска грешка ја претвора во непроверена врска. Оваа поделба е доволно стара за да биде стандардизирана: имплицитниот 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 режимот што ги користи клиентот, патеката што ја помина пораката и одговорот што го врати серверот. Овие четири факти нејасниот проблем со излезното сандаче го претвораат во промена што некој може да ја прегледа.