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

สามรูปแบบ หน้าจอเดียวที่เหมือนกัน

ทั้งสามแบบจบลงด้วยอีเมลที่ปรากฏบนอุปกรณ์ และหน้าจอการตั้งค่าดูเหมือนกันในทุกกรณี สิ่งที่ต่างกันคือใครเป็นผู้กำหนดเส้นทางและหลักฐานใดที่พิสูจน์ว่ามันมีอยู่

ArrangementWho set it upWhat proves it
Approved public mail entryThe service owner, at the publishing layerA published endpoint reached over TLS with its own authentication
Managed app or account VPNDevice management, as explicit policyA profile binding that traffic to a VPN association
Already active tunnelAn always-on service or an earlier manual connectTunnel state plus routes and scope that include the mail destination

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

สิ่งที่การจัดการอุปกรณ์ผูกได้จริง

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

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

ตัวตนและการขนส่งยังแยกจากกัน

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

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

การซิงค์ใหม่ชนะกล่องจดหมายที่แคชไว้

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

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

เขียนสิ่งที่คุณตรวจสอบแล้ว

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

บันทึกการสนับสนุนควรระบุผลิตภัณฑ์อีเมล จุดสิ้นสุด ขอบเขตบัญชี และนโยบายการเชื่อมต่อ รหัสผ่านที่เหมือนกันไม่ใช่หลักฐานของทั้งสี่ข้อนั้น และนี่คือเหตุผลที่พบบ่อยที่สุดที่ตั๋วมีสี่ย่อหน้าและไม่มีข้อเท็จจริง

บทความที่เกี่ยวข้อง