การส่งอีเมลล้มเหลวเมื่อ 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 ที่ไคลเอนต์ใช้ เส้นทางที่ข้อความไป และการตอบกลับที่เซิร์ฟเวอร์ส่งคืนได้ ข้อเท็จจริงสี่ข้อนี้เปลี่ยนปัญหากล่องขาออกที่คลุมเครือให้เป็นการเปลี่ยนแปลงที่ใครบางคนตรวจสอบได้