Sähköpostin lähetys epäonnistuu, kun VPN yhdistyy: etsi vaihe

Sähköposti, joka toimi koko aamun, pysähtyy heti, kun tunneli nousee, ja ensimmäinen vaisto on kirjoittaa salasana uudelleen. Tämä vaisto ohittaa hyödyllisemmän kysymyksen: pääsikö asiakas ylipäätään palvelimelle ja etenikö se tarpeeksi pitkälle tarjotakseen tunnistetiedot? Aikakatkaisu, varmentovirhe ja hylkäysvastaus ovat kolme eri vikaa, ja vain kolmas liittyy tiliin. Käy vaiheet järjestyksessä läpi, niin VPN:stä tulee muuttuja, jota voit testata, eikä syyllinen, jota syytät.

Vaihe 1: luokittele vika ennen kuin kosket tunnistetietoihin

Lue virhe, jonka sovellus todella tuotti, ja aseta se yhteen kolmesta korista. Aikakatkaisu tai yhteyden nollaus tarkoittaa, että TCP-reitti petti; TLS- tai varmentovirhe tarkoittaa, että reitti toimi ja kättely ei; SMTP-vastaus koodilla tarkoittaa, että postipalvelin vastasi ja teki päätöksen. Jokainen kori osoittaa eri vastuulliseen.

Korit kannattaa erottaa, koska korjaukset ovat ristiriidassa. Aikakatkaisun pidentäminen ei auta, kun palvelin hylkää lähettäjän, eikä salasanan vaihtaminen tee mitään, kun reitti on estetty. Vastauskoodi on listan arvokkain todiste, koska se todistaa, että koko kuljetusketju toimi ja ongelma on käytännössä tai identiteetissä. Tallenna tarkka teksti, mukaan lukien mahdollinen laajennettu tilakoodi, ennen kuin yrität uudelleen.

Pysähdy tähän, jos et voi toistaa vikaa VPN:n ulkopuolella. Ongelma, joka ilmenee yhdessä sovelluksessa yhdellä koneella, ei ole vielä verkko-ongelma.

Vaihe 2: vahvista päätepiste ja TLS-tila

Viestien lähetys on oma palvelunsa, ei sama asia kuin palvelimelta palvelimelle välittäminen. Vahvista isäntänimi, portti ja TLS-tila palveluntarjoajan lähetysohjeista, koska toisesta sähköpostiasetuksesta lainattu tuttu portti ei ole todiste. Portti 587 odottaa selkokielistä tervehdystä ja sen jälkeen STARTTLS:ää, kun taas portti 465 odottaa TLS:ää ensimmäisestä tavusta.

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

Väärän kahdesta testistä suorittaminen on juuri se virhe, jonka asiakas tekee, kun se on määritetty toiseen tilaan. Jos implisiittisen TLS:n testi jumittuu portissa 587 tai STARTTLS-testi epäonnistuu portissa 465, portti ja tila eivät vastaa toisiaan. Korjaa tila asiakkaassa sen sijaan, että poistat varmenteen tarkistuksen käytöstä, mikä muuttaa asetusvirheen tarkistamattomaksi yhteydeksi. Jako on tarpeeksi vanha ollakseen standardoitu: implisiittinen TLS portissa 465 on järjestely, joka on kuvattu dokumentissa RFC 8314.

Varmentovirhe on tässä tietoa, ei este. Se nimeää identiteetin, jonka palvelin esitti, ja identiteetin, jota asiakas odotti, ja molemmat voidaan korjata heikentämättä yhteyttä.

Vaihe 3: vertaa reittejä muuttamatta tiliä

Pidä päätepiste, tili ja asiakasasetukset muuttumattomina ja muuta vain reittiä. Lähetä kerran tunneli alhaalla ja kerran ylhäällä ja kirjaa reitti ja lähdeosoite, jonka palvelin näkisi. Jos vika seuraa reittiä, olet eristänyt sen; jos se seuraa konetta, et.

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

Täystunneli muuttaa lähdeosoitetta, jonka palveluntarjoaja näkee, ja jotkin tarjoajat kohtelevat tuntematonta lähdettä tiukemmin kuin tuntematonta salasanaa. Se on heidän puolellaan käytäntöpäätös, ja se voi olla harmaa lista, nopeusrajoitus tai esto. Älä yleistä yhdestä tarjoajasta kaikkiin äläkä oleta, että puuttuva NAT-sääntö selittää jokaisen vian. curl-loki näyttää, mikä vaihe epäonnistui, vaikka sovelluksen oma loki ei näyttäisi.

Jos tunnelin on tarkoitus kuljettaa internettiliikennettä, sekä sen reitityksen että lähtökäytännön on sallittava tämä kohde. Tunneli, joka kuljettaa vain yksityisiä reittejä, jättää sähköpostiyhteyden paikalliselle reitille, mikä on eri vertailu.

Vaihe 4: lähetä yksi harmiton viesti ja kirjaa vastaus

Korjaa vaihe, joka epäonnistui, ja lähetä sitten yksi harmiton viesti saman sovelluksen kautta, ei verkkopostisivun kautta. Testaat sovelluksen omaa lähetysreittiä, mukaan lukien sen tallennetut asetukset ja TLS-tila. Verkkopostisessio ei todista siitä mitään.

Kirjaa vastaus, portti, TLS-tila ja käyttämäsi reitti, jotta seuraava henkilö voi toistaa tuloksen. Toimiva selain ja vihreä VPN-kuvake ovat havaintoja muista asioista. Jos viesti saapuu, jäljellä on tehdä tästä asetuksesta oletus jokaiselle koneelle, joka lähettää tämän tilin kautta.

Tarkistuslista on valmis, kun voit nimetä vaiheen, joka epäonnistui, asiakkaan käyttämän portin ja TLS-tilan, reitin, jonka viesti kulki, ja vastauksen, jonka palvelin palautti. Nämä neljä tosiasiaa muuttavat epämääräisen lähtevien ongelman muutokseksi, jonka joku voi tarkistaa.