Слање поште не успева када се 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 режим које клијент користи, путању којом је порука ишла и одговор који је сервер вратио. Те четири чињенице претварају нејасан проблем са одлазним сандучетом у промену коју неко може да прегледа.

Повезани чланци