VPN เชื่อมต่อแล้วแต่ IMAP ไม่ซิงค์? ตรวจสอบสามชั้นนี้

เชื่อมต่อ VPN ของออฟฟิศ เปิดไคลเอนต์เมล แล้วสังเกตว่ากล่องขาเข้าปฏิเสธการรีเฟรชในขณะที่เว็บเมลโหลดได้ตามปกติ การวินิจฉัยทั่วไปคือ VPN ส่งผ่านทราฟฟิกแต่บล็อกเมล หรือรหัสผ่านของบัญชีเปลี่ยนไป ทั้งสองข้อสันนิษฐานข้ามโครงสร้างของสิ่งที่ไคลเอนต์ IMAP ทำ การไปถึงโฮสต์ การทำ TLS ให้เสร็จ การยืนยันตัวตน และการเลือกกล่องจดหมายเป็นสี่เหตุการณ์ที่ต่างกัน และ VPN เป็นเจ้าของเพียงเหตุการณ์แรก

ความเชื่อผิด: การเชื่อมต่อหนึ่งครั้งหมายถึงการลงชื่อเข้าใช้หนึ่งครั้ง

มีความเชื่อว่าเมื่ออุโมงค์ตั้งขึ้นและเซิร์ฟเวอร์เมลตอบกลับ กล่องจดหมายก็เปิดอยู่จริง ไม่ใช่เช่นนั้น VPN ให้เส้นทางไปยังบริการ แต่ไม่ได้ลงชื่อเข้าใช้ให้คุณและไม่ได้เลือกโฟลเดอร์ ไคลเอนต์อาจหยุดอยู่ที่ขั้นตอนที่สี่จากขั้นตอนเหล่านั้นทั้งที่มีอุโมงค์ทำงานสมบูรณ์และรหัสผ่านที่ถูกต้อง

ช่องว่างนี้นี่เองคือที่อยู่ของรายงาน «IMAP ใช้ผ่าน VPN ไม่ได้» ส่วนใหญ่

สามสถานะของ IMAP และจุดที่ไคลเอนต์ค้างอยู่

IMAP กำหนดสถานะที่ยังไม่ยืนยันตัวตน สถานะที่ยืนยันตัวตนแล้ว และสถานะที่เลือกแล้ว และคำสั่งจะใช้ได้เฉพาะในสถานะที่อนุญาตเท่านั้น การเชื่อมต่ออาจเริ่มต้นโดยยืนยันตัวตนแล้วเมื่อเซิร์ฟเวอร์เสนอการยืนยันตัวตนล่วงหน้า ดังนั้นการไม่มีคำขอรหัสผ่านจึงไม่ได้พิสูจน์อะไร การเลือกกล่องจดหมายย้ายเซสชันจากยืนยันตัวตนแล้วไปเป็นเลือกแล้ว และเมื่อนั้นคำสั่งที่กระทำต่อข้อความจึงมีเป้าหมาย

ไคลเอนต์ที่ยืนยันตัวตนสำเร็จแล้วแต่เลือกโฟลเดอร์ที่กำหนดไว้ไม่ได้จะดูเหมือนความล้มเหลวในการซิงค์ในขณะที่เซิร์ฟเวอร์ทำงานถูกต้อง โฟลเดอร์ที่เปลี่ยนชื่อ ผู้ให้บริการที่แมป «กล่องขาเข้า» ต่างออกไป หรือสิทธิ์การเข้าถึงที่หายไปล้วนมาจบที่นี่ การตอบกลับ NO ที่ติดแท็กของเซิร์ฟเวอร์คือหลักฐาน และไม่ใช่การตอบกลับแบบเดียวกับรหัสผ่านที่ถูกปฏิเสธ

TLS มาก่อนการสนทนา IMAP

ด้วย TLS แบบโดยนัยบนพอร์ต 993 การทำ TLS แฮนด์เชกจะเสร็จก่อนที่จะมีการส่งคำสั่ง IMAP ใด ๆ จึงเป็นเหตุให้ปัญหาใบรับรองสร้างข้อผิดพลาดที่กล่าวถึงความไว้วางใจไม่ใช่เมล ชื่อโฮสต์ของเมลต้องผ่านการตรวจสอบกับใบรับรอง เช่นเดียวกับชื่อโฮสต์เว็บ; อุโมงค์ที่รักษาทราฟฟิกไม่ได้ทำให้ใบรับรองที่ไม่ถูกต้องกลายเป็นถูกต้อง

ข้อความแสดงข้อผิดพลาดแยกกรณีออกจากกัน การหมดเวลาการเชื่อมต่อหมายถึง SYN ไม่เคยเสร็จสมบูรณ์ ข้อผิดพลาด TLS หมายถึงการเชื่อมต่อ TCP ทำงานแต่แฮนด์เชกไม่ทำงาน การตอบกลับ IMAP NO หรือ BAD หมายถึงทั้งสองสำเร็จและชั้นโปรโตคอลปฏิเสธบางอย่าง บันทึกว่าคุณเห็นแบบไหนก่อนเปลี่ยนการตั้งค่าใด ๆ

เมลที่แคชไว้ไม่ใช่หลักฐานของสิ่งใด

ไคลเอนต์เมลแสดงข้อความที่ดาวน์โหลดไว้ก่อนหน้าไม่ว่าจะเข้าถึงเซิร์ฟเวอร์ได้ในวันนี้หรือไม่ ดังนั้นกล่องขาเข้าที่แสดงอยู่บอกคุณเพียงว่าที่เก็บข้อมูลในเครื่องทำงาน การทดสอบจริงใด ๆ ต้องบังคับให้เกิดการดำเนินการบนเซิร์ฟเวอร์ รีเฟรชโฟลเดอร์ ดึงข้อความที่ไม่เคยดาวน์โหลด หรือส่งคำสั่งที่ไคลเอนต์จะออกให้หลังเลือกกล่องจดหมายเท่านั้น

ใช้การตรวจสอบที่ไม่ทำลายข้อมูล การรีเฟรชโฟลเดอร์เดียวและอ่านบันทึกข้อผิดพลาดของบัญชีดีกว่าการลบบัญชีแล้วเพิ่มใหม่ ซึ่งส่วนใหญ่พิสูจน์เพียงว่าหน้าจอการตั้งค่ายังทำงาน

การส่งเมลและเว็บเมลเป็นโปรโตคอลต่างกัน

การส่งเมลคือการส่งมอบ ไม่ใช่ IMAP ใช้บริการแยกและโดยปกติใช้พอร์ตแยกที่มีโหมด TLS ของตัวเองและการยืนยันตัวตนของตัวเอง ดังนั้นกล่องขาออกที่ทำงานไม่ได้พิสูจน์ว่าเลือกกล่อง IMAP แล้ว และกล่องขาออกที่เสียก็ไม่ได้กล่าวโทษ IMAP

เว็บเมลต่างออกไปอีก สามารถสำเร็จผ่าน VPN เดียวกันได้เพราะเป็นเซสชัน HTTPS กับส่วนหน้าเว็บ ซึ่งไม่ได้บอกอะไรเกี่ยวกับโฮสต์ IMAP พอร์ต หรือโหมด TLS ของไคลเอนต์เดสก์ท็อป

สำหรับการส่งต่อ บันทึกผลลัพธ์สี่อย่างแยกกัน เส้นทาง VPN ผลของปลายทางเมลและ TLS ผลของการยืนยันตัวตนบัญชี และผลของการเลือกกล่องจดหมาย เก็บข้อมูลรับรองและเนื้อหาข้อความไว้นอกบันทึก บันทึกนั้นบอกคนถัดไปว่าการแก้ไขเป็นของเครือข่าย ใบรับรอง บัญชี หรือการกำหนดค่าโฟลเดอร์ โดยไม่ทำให้ชั้นป้องกันใดอ่อนแอลง