Retpoŝta sendado malsukcesas kiam la VPN konektiĝas: trovu la etapon

Retpoŝto, kiu funkciis la tutan matenon, haltas en la momento kiam la tunelo supreniĝas, kaj la unua impulso estas retajpi la pasvorton. Tiu impulso preterlasas la pli utilan demandon: ĉu la kliento entute atingis la servilon, kaj ĉu ĝi iris sufiĉe malproksimen por proponi legitimilojn? Tempolimo, atestila eraro kaj rifuza respondo estas tri malsamaj fiaskoj, kaj nur la tria koncernas la konton. Trapasu la etapojn laŭ ordo kaj la VPN fariĝas variablo, kiun vi povas testi, anstataŭ suspektito, kiun vi kulpas.

Etapo 1: klasifiku la fiaskon antaŭ ol tuŝi legitimilojn

Legu la eraron, kiun la aplikaĵo efektive produktis, poste metu ĝin en unu el tri korboj. Tempolimo aŭ rekomencigo de la konekto signifas, ke la TCP-vojo fiaskis; TLS- aŭ atestila eraro signifas, ke la vojo funkciis kaj la manpremo ne; SMTP-respondo kun kodo signifas, ke retpoŝta servilo respondis kaj decidis. Ĉiu korbo montras al malsama respondeculo.

Indas apartigi la korbojn, ĉar la riparoj kontraŭdiras unu la alian. Plilongigi tempolimon helpas neniom, kiam la servilo rifuzas la sendanton, kaj ŝanĝi pasvorton faras nenion, kiam la vojo estas blokita. Responda kodo estas la plej valora pruvo en la listo, ĉar ĝi pruvas, ke la tuta transporta ĉeno funkciis kaj ke la problemo estas politiko aŭ identeco. Konservu la precizan tekston, inkluzive de ajna plilongigita statusa kodo, antaŭ ol reprovi.

Haltu ĉi tie, se vi ne povas reprodukti la fiaskon ekster la VPN. Problemo, kiu aperas en unu aplikaĵo sur unu maŝino, ankoraŭ ne estas reta problemo.

Etapo 2: konfirmu la finpunkton kaj la TLS-reĝimon

Sendado de mesaĝoj estas propra servo, ne la sama afero kiel plusendo de servilo al servilo. Konfirmu la gastigantan nomon, la pordon kaj la TLS-reĝimon el la dokumentaro de la provizanto por sendado, ĉar konata pordo pruntita el alia retpoŝta agordo ne estas pruvo. Pordo 587 atendas saluton en klara teksto sekvatan de STARTTLS, dum pordo 465 atendas TLS ekde la unua bajto.

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

Ruli la malĝustan el tiuj du provoj estas ĝuste la eraro, kiun la kliento faras, kiam ĝi estas agordita por la alia reĝimo. Se la provo de implica TLS pendas ĉe 587, aŭ la provo de STARTTLS fiaskas ĉe 465, la pordo kaj la reĝimo ne kongruas. Riparu la reĝimon en la kliento anstataŭ malŝalti atestilan kontroladon, kiu transformas agordan eraron en nekontrolitan konekton. La divido estas sufiĉe malnova por esti normigita: implica TLS ĉe pordo 465 estas la aranĝo priskribita en RFC 8314.

Atestila eraro ĉi tie estas informo, ne obstaklo. Ĝi nomas la identecon, kiun la servilo prezentis, kaj la identecon, kiun la kliento atendas, kaj ambaŭ estas ripareblaj sen malfortigi la konekton.

Etapo 3: komparu vojojn sen ŝanĝi la konton

Tenu la finpunkton, la konton kaj la klientajn agordojn konstantaj kaj ŝanĝu nur la vojon. Sendu unufoje kun mallevita tunelo kaj unufoje kun levita, kaj notu la itineron kaj la fontan adreson, kiun la servilo vidus. Se la fiasko sekvas la vojon, vi izolis ĝin; se ĝi sekvas la maŝinon, vi ne izolis.

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

Plena tunelo ŝanĝas la fontan adreson, kiun la provizanto vidas, kaj kelkaj provizantoj traktas nekonatan fonton pli strikte ol nekonatan pasvorton. Tio estas politika decido ĉe ilia flanko, kaj ĝi povas esti griza listo, rapidlimo aŭ blokado. Ne ĝeneraligu de unu provizanto al ĉiuj, kaj ne supozu, ke mankanta NAT-regulo klarigas ĉiun fiaskon. La protokolo de curl montras, kiu etapo fiaskis, eĉ kiam la propra protokolo de la aplikaĵo ne montras tion.

Se la tunelo devas porti interretan trafikon, ĝia kursado kaj ĝia elira politiko ambaŭ devas permesi ĉi tiun celon. Tunelo, kiu portas nur privatajn itinerojn, lasas la retpoŝtan konekton sur la loka vojo, kio estas alia komparo.

Etapo 4: sendu unu senriskan mesaĝon kaj notu la respondon

Riparu la etapon, kiu fiaskis, poste sendu unu senriskan mesaĝon tra la sama aplikaĵo, ne tra retpoŝta reteja paĝo. Vi testas la propran sendvojon de la aplikaĵo, inkluzive de ĝiaj konservitaj agordoj kaj ĝia TLS-reĝimo. Retpoŝta reta seanco pruvas nenion pri tio.

Notu la respondon, la pordon, la TLS-reĝimon kaj la vojon, kiun vi uzis, por ke la sekva persono povu reprodukti la rezulton. Funkcianta retumilo kaj verda VPN-ikono estas observoj pri aliaj aferoj. Se la mesaĝo alvenas, la restanta laboro estas fari tiun agordon la defaŭlto por ĉiu maŝino, kiu sendas tra ĉi tiu konto.

La kontrol-listo estas kompleta, kiam vi povas nomi la etapon, kiu fiaskis, la pordon kaj TLS-reĝimon, kiujn la kliento uzas, la vojon, kiun la mesaĝo iris, kaj la respondon, kiun la servilo redonis. Tiuj kvar faktoj transformas nebulan problemon de elirejo en ŝanĝon, kiun iu povas revizii.