อีเมลไปถึงเซิร์ฟเวอร์ได้โดยไม่ต้องใช้ VPN: จะบังคับใช้กฎที่ใด
แอปอีเมลยังเข้าถึงเซิร์ฟเวอร์ได้ขณะที่ VPN ถูกปิด ตัดสินใจว่าบริการอีเมลปฏิเสธไคลเอนต์โดยตรง หรือ Mac ไม่พยายามเลย
อีเมลยังคงถามหาตลอดและ VPN ถูกปิด แต่บัญชียังซิงก์อยู่ แอปทำตามที่กำหนดค่าไว้ ไม่มีอะไรในโปรไฟล์อีเมลปกติที่บอกว่าเซิร์ฟเวอร์เข้าถึงได้ผ่านอุโมงค์เท่านั้น นั่นทำให้เหลือข้อกำหนดสองแบบที่ต่างกัน และสับสนได้ง่าย บริการควรปฏิเสธไคลเอนต์โดยตรง หรือ Mac ไม่ควรพยายามเลย
เลือกข้อกำหนดก่อนเลือกผลิตภัณฑ์ กฎฝั่งเซิร์ฟเวอร์และกฎฝั่งไคลเอนต์ล้มเหลวคนละที่ ให้หลักฐานคนละแบบ และเป็นของเจ้าของคนละคน การบังคับใช้ทั้งสองแบบสมเหตุสมผลเมื่อข้อความทั้งสองเป็นจริง แต่อย่างหนึ่งไม่ใช่สิ่งทดแทนอีกอย่าง ข้อกำหนดทั้งสองถูกต้อง เพียงแต่ไม่ใช่การควบคุมเดียวกัน
อาการดูเหมือนอยู่ที่ Mac แต่การรั่วอาจอยู่ที่เซิร์ฟเวอร์
เมื่ออีเมลซิงก์นอกอุโมงค์ ให้เริ่มจากสิ่งที่เซิร์ฟเวอร์ยอมรับ ถ้าตัวรับฟังอีเมลตอบรับการเชื่อมต่อโดยตรงจากอินเทอร์เน็ต การตั้งค่าเพื่อความสะดวกฝั่งไคลเอนต์ก็ไม่เปลี่ยนข้อเท็จจริงนั้น Mac ทำงานปกติกับบริการที่ยังเปิดอยู่
ถามผู้ดูแลอีเมลว่าบริการเห็นที่อยู่ต้นทางใด เกตเวย์ VPN พร็อกซีย้อนกลับ หรือตัวกระจายโหลดอาจแปลงที่อยู่ไคลเอนต์ กลุ่มที่อยู่ในคอนฟิก VPN จึงอาจไม่ตรงกับสิ่งที่มาถึงโปรเซสอีเมล กฎที่เขียนกับต้นทางผิดจะบล็อกทุกคนหรือไม่บล็อกใครเลย
คำตอบนั้นยังบอกด้วยว่าบริการแยกไคลเอนต์ VPN ได้หรือไม่ ถ้าไคลเอนต์ทุกตัวมาจากที่อยู่พร็อกซีเดียวกัน การรับเข้าตามต้นทางแยกพวกเขาไม่ได้ และข้อกำหนดต้องย้ายไปที่การพิสูจน์ตัวตนหรือฝั่งไคลเอนต์
การรับเข้าที่เซิร์ฟเวอร์: ปฏิเสธต้นทาง ไม่ใช่แอป
ไฟร์วอลล์ของโฮสต์หรือเครือข่ายจำกัดตัวรับฟังอีเมลให้อยู่ในช่วงต้นทางที่อนุมัติ โดยไม่แตะการพิสูจน์ตัวตนและ TLS เงื่อนไขกฎที่ตรงกับที่อยู่ระยะไกล ซับเน็ต หรือช่วงคือองค์ประกอบปกติ ส่วนไวยากรณ์ที่แน่นอนเป็นของผลิตภัณฑ์ไฟร์วอลล์ของเซิร์ฟเวอร์ ไม่ใช่แอปอีเมล
นี่คือขอบเขตที่แข็งแรงที่สุดเมื่อข้อกำหนดคือ «บริการต้องไม่ให้บริการไคลเอนต์โดยตรง» ยังคงอยู่แม้ผู้ใช้ติดตั้งไคลเอนต์อีเมลตัวอื่น เพราะการปฏิเสธเกิดก่อนการพิสูจน์ตัวตน ยังทนต่อ Mac ที่เพิกเฉยต่อนโยบาย VPN ของตน
ขีดจำกัดของมันสำคัญพอ ๆ กัน การเชื่อมต่อที่ถูกปฏิเสธพิสูจน์ว่าบริการปฏิเสธเซสชัน ไม่ได้พิสูจน์ว่า Mac ไม่ได้พยายาม การแปลง DNS, TCP SYN ไปยังตัวกระจายโหลดก่อนหน้า และการลองใหม่หลังล้มเหลว ล้วนเกิดได้ก่อนถึงกฎของเซิร์ฟเวอร์ ถ้าข้อกำหนดเกี่ยวกับการเปิดเผยความพยายามไม่ใช่การเข้าถึง การรับเข้าที่เซิร์ฟเวอร์เป็นเพียงครึ่งหนึ่งของการควบคุม
การบังคับใช้ที่ไคลเอนต์: บล็อกความพยายาม ไม่ใช่แค่อุโมงค์
กฎฝั่งไคลเอนต์ต้องห้ามทราฟฟิก ไม่ใช่แค่เริ่มอุโมงค์เมื่อเปิดอีเมล ทริกเกอร์เปิดใช้งานสำหรับโดเมนอีเมลยก VPN ขึ้นได้ในจังหวะที่เหมาะสม แต่ไม่ได้กำหนดว่าเกิดอะไรขึ้นขณะอุโมงค์ล่มหรือหลังล้มเหลว
ใช้นโยบายบล็อกที่ผลิตภัณฑ์ปลายทางรองรับ และกำหนดขอบเขตอย่างตั้งใจ กฎระดับแอปครอบทุกบัญชีในแอปอีเมลนั้น รวมถึงบัญชีส่วนตัว กฎระดับปลายทางต้องระบุปลายทาง IMAP การส่ง และการพิสูจน์ตัวตนของบัญชีงาน และต้องทำงานต่อเมื่อที่อยู่เหล่านั้นเปลี่ยน
ครอบทั้งสองตระกูลที่อยู่และเซสชันที่มีอยู่ นโยบายที่บล็อกการเชื่อมต่อ IPv4 ใหม่แต่ปล่อย IPv6 หรือซ็อกเก็ตที่ตั้งไว้แล้วทำให้เกิดการซิงก์เป็นช่วง ๆ ที่ดูเหมือนสุ่ม การเปลี่ยนเครือข่ายและรอบการหลับเป็นส่วนหนึ่งของการทดสอบเดียวกัน
กฎระดับแอปและระดับปลายทางมีขอบเขตผลกระทบต่างกัน
การบล็อกระดับแอปเข้าใจง่าย ไม่มีทราฟฟิกจาก Mail ออกไปโดยไม่มีอุโมงค์ แต่ก็หยาบ เพราะแอปเดียวกันอาจมีบัญชีส่วนตัวที่ไม่เกี่ยวกับนโยบายเลย ผู้ใช้สังเกตเห็นสิ่งนี้ก่อนและรายงานว่าแอปอีเมลเสีย
การบล็อกระดับปลายทางแคบกว่าและดูแลยากกว่า ต้องมีชุดปลายทางทั้งหมดที่บัญชีใช้ รวมถึงบริการค้นหาและการพิสูจน์ตัวตน และกระบวนการอัปเดตสิ่งเหล่านั้น พลาดไปหนึ่งบัญชีก็ทำงานครึ่ง ๆ ถ้าใส่มากเกินไปอีเมลที่ไม่เกี่ยวข้องก็หยุด
เลือกตามถ้อยคำของข้อกำหนด «บัญชีงานนี้ต้องไม่เชื่อมต่อโดยตรง» ชี้ไปที่ขอบเขตปลายทาง «Mac นี้ต้องไม่รันอีเมลนอก VPN» ให้เหตุผลกับกฎระดับแอปที่กว้างกว่า หากเจ้าของยอมรับผลข้างเคียงต่อบัญชีส่วนตัว
ทดสอบการปฏิเสธและการไม่พยายามแยกกัน
ด้วยบัญชีทดสอบเฉพาะ เชื่อมต่อผ่าน VPN และยืนยันการทำงานปกติ จากนั้นตัดการเชื่อมต่อและทดสอบสองครั้ง ครั้งหนึ่งดูว่าเซิร์ฟเวอร์ปฏิเสธการเข้าสู่ระบบหรือไม่ อีกครั้งดูว่า Mac พยายามเชื่อมต่อหรือไม่เลย สิ่งเหล่านี้เป็นการสังเกตที่ต่างกันและอยู่ในบันทึกที่ต่างกัน
ดูหลักฐานฝั่งไคลเอนต์สำหรับ SYN หรือคำถาม DNS ขณะตัดการเชื่อมต่อ และดูบันทึกฝั่งเซิร์ฟเวอร์สำหรับเซสชันที่ถูกปฏิเสธหรือยอมรับ ถ้าเซิร์ฟเวอร์ปฏิเสธแต่ไคลเอนต์ยังพยายาม กฎเซิร์ฟเวอร์ทำงานและกฎไคลเอนต์หายไป ถ้าไคลเอนต์ไม่พยายามแต่เซิร์ฟเวอร์ยังรับไคลเอนต์อื่น ขอบเขตอยู่ตรงที่คุณวางไว้พอดี
บันทึกเจ้าของการบังคับใช้ ที่อยู่ต้นทางที่เซิร์ฟเวอร์เห็นจริง และบัญชีทดสอบที่ใช้ การเปลี่ยนเครือข่ายหรือพร็อกซีครั้งถัดไปอาจเลื่อนต้นทางนั้น และบันทึกที่ระบุค่าที่สังเกตได้ตรวจสอบได้เร็วกว่าการเดาอีกครั้ง