A levélküldés meghiúsul, amikor a VPN csatlakozik: találja meg a szakaszt

A levél, amely egész délelőtt működött, abban a pillanatban leáll, amikor az alagút feljön, és az első ösztön a jelszó újragépelése. Ez az ösztön kihagyja a hasznosabb kérdést: elérte-e az ügyfél egyáltalán a kiszolgálót, és eljutott-e elég messzire ahhoz, hogy hitelesítő adatokat ajánljon? Az időtúllépés, a tanúsítványhiba és az elutasító válasz három különböző hiba, és csak a harmadik érinti a fiókot. Járja végig a szakaszokat sorrendben, és a VPN tesztelhető változóvá válik ahelyett, hogy bűnbak lenne.

1. szakasz: osztályozza a hibát, mielőtt a hitelesítő adatokhoz nyúlna

Olvassa el a hibát, amelyet az alkalmazás valóban előállított, majd helyezze el a három kosár egyikébe. Az időtúllépés vagy a kapcsolat visszaállítása azt jelenti, hogy a TCP-útvonal meghiúsult; a TLS- vagy tanúsítványhiba azt jelenti, hogy az útvonal működött, a kézfogás nem; a kóddal ellátott SMTP-válasz azt jelenti, hogy egy levélkiszolgáló válaszolt és döntött. Minden kosár más felelősre mutat.

Érdemes szétválasztani a kosarakat, mert a javítások ellentmondanak egymásnak. Az időtúllépés meghosszabbítása nem segít, amikor a kiszolgáló elutasítja a feladót, és a jelszó megváltoztatása semmit sem tesz, amikor az útvonal blokkolt. A válaszkód a lista legértékesebb bizonyítéka, mert bizonyítja, hogy az egész szállítási lánc működött, és a probléma szabályzat vagy identitás kérdése. Mentse el a pontos szöveget, beleértve bármely kiterjesztett állapotkódot, mielőtt újra próbálkozik.

Álljon meg itt, ha a hibát nem tudja a VPN-en kívül reprodukálni. Az egy gépen, egy alkalmazásban jelentkező probléma még nem hálózati probléma.

2. szakasz: erősítse meg a végpontot és a TLS-módot

Az üzenetküldés önálló szolgáltatás, nem ugyanaz, mint a kiszolgáló-kiszolgáló továbbítás. Erősítse meg a gazdagépnevet, a portot és a TLS-módot a szolgáltató küldésre vonatkozó dokumentációjából, mert egy másik levélbeállításból kölcsönzött ismerős port nem bizonyíték. Az 587-es port egyszerű szöveges üdvözlést és utána STARTTLS-t vár, míg a 465-es port TLS-t vár az első bájttól.

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

A két próba közül a rosszat lefuttatni pontosan az a hiba, amelyet az ügyfél elkövet, amikor a másik módra van beállítva. Ha az implicit TLS próbája megakad az 587-en, vagy a STARTTLS próbája meghiúsul a 465-ön, a port és a mód nem egyezik. Javítsa a módot az ügyfélben ahelyett, hogy kikapcsolná a tanúsítvány-ellenőrzést, ami egy konfigurációs hibát ellenőrizetlen kapcsolattá alakít. A felosztás elég régi ahhoz, hogy szabványos legyen: az implicit TLS a 465-es porton az az elrendezés, amelyet a RFC 8314 ír le.

A tanúsítványhiba itt információ, nem akadály. Megnevezi azt az identitást, amelyet a kiszolgáló bemutatott, és azt, amelyet az ügyfél várt, és mindkettő javítható a kapcsolat gyengítése nélkül.

3. szakasz: hasonlítsa össze az útvonalakat a fiók módosítása nélkül

Tartsa állandón a végpontot, a fiókot és az ügyfél beállításait, és csak az útvonalat változtassa meg. Küldjön egyszer leengedett alagúttal és egyszer felemelttel, és jegyezze fel az útvonalat és azt a forrásoldali címet, amelyet a kiszolgáló látna. Ha a hiba követi az útvonalat, izolálta; ha a gépet követi, nem.

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

A teljes alagút megváltoztatja azt a forráscímet, amelyet a szolgáltató lát, és egyes szolgáltatók szigorúbban kezelik az ismeretlen forrást, mint az ismeretlen jelszót. Ez az ő oldalukon szabályzati döntés, és lehet szürke lista, sebességkorlát vagy blokk. Ne általánosítson egy szolgáltatóról mindenkire, és ne feltételezze, hogy egy hiányzó NAT-szabály minden hibát megmagyaráz. A curl-napló megmutatja, melyik szakasz hiúsult meg, akkor is, ha az alkalmazás saját naplója nem.

Ha az alagútnak internetforgalmat kell szállítania, akkor az útválasztásnak és a kimeneti szabályzatnak is engedélyeznie kell ezt a célállomást. Az az alagút, amely csak privát útvonalakat szállít, a levélkapcsolatot a helyi útvonalon hagyja, ami más összehasonlítás.

4. szakasz: küldjön egy ártalmatlan üzenetet, és jegyezze fel a választ

Javítsa ki a meghiúsult szakaszt, majd küldjön egy ártalmatlan üzenetet ugyanazon alkalmazáson keresztül, nem egy webmail-oldalon. Az alkalmazás saját küldési útvonalát teszteli, beleértve a tárolt beállításait és a TLS-módját. Egy webmail-munkamenet semmit sem bizonyít erről.

Jegyezze fel a választ, a portot, a TLS-módot és az általa használt útvonalat, hogy a következő ember reprodukálhassa az eredményt. A működő böngésző és a zöld VPN-ikon más dolgokra vonatkozó megfigyelések. Ha az üzenet megérkezik, a hátralévő munka az, hogy ezt a konfigurációt alapértelmezetté tegye minden gépen, amely ezen a fiókon keresztül küld.

Az ellenőrzőlista akkor teljes, ha meg tudja nevezni a meghiúsult szakaszt, az ügyfél által használt portot és TLS-módot, az üzenet útvonalát és a kiszolgáló által visszaadott választ. Ez a négy tény egy homályos kimenő postafiók-problémát olyan változtatássá alakít, amelyet valaki átnézhet.