VPN สองตัวบน iPhone พร้อมกัน: ตัวไหนพาทราฟฟิกของคุณไป?

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

ความเชื่อผิด: VPN สองตัวที่เชื่อมต่อกันคือห่วงโซ่

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

หากคุณต้องการการซ้อนกัน ให้ออกแบบเป็นการซ้อนกัน อย่าอนุมานจากตัวบ่งชี้การเชื่อมต่อสองตัว ความแตกต่างนี้ประหยัดการดีบักได้มาก

รูปแบบที่มีเอกสารกำกับอยู่เบื้องหลังความเชื่อผิดนั้น

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

Personal VPN ในที่นี้คือศัพท์ API สำหรับการใช้งาน IPsec หรือ IKEv2 ที่มีมาในตัวซึ่งจัดการผ่าน NEVPNManager NETunnelProviderManager คือรูปแบบผู้ให้บริการอุโมงค์ แอปสำหรับผู้บริโภคสามารถใช้รูปแบบผู้ให้บริการได้ ดังนั้นชื่อผลิตภัณฑ์ที่มี personal จึงไม่ได้จัดประเภทมัน

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

ความเชื่อผิด: VPN ส่วนตัวได้รับการทราฟฟิกการท่องเว็บ

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

คอนฟิกูเรชันที่จัดการแยกตามแอปมีขอบเขตของตัวเอง อย่าขยายกฎระดับอุปกรณ์ไปยังทุกการติดตั้งที่จัดการ

จดโฟลว์ทั้งสองก่อนทดสอบ: ชื่อและช่วงส่วนตัวของบริการงาน และคำขอท่องเว็บสาธารณะใหม่ ทั้งสองถูกต้อง และต้องใช้การตรวจสอบต่างกัน

ลำดับความสำคัญของเส้นทางกับโปรไฟล์งานที่มีอุโมงค์แยก

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

เขียนคู่เป็นสองบรรทัดและระบุผู้ชนะที่คาดหวังของแต่ละรายการ: ชื่อโฮสต์งานที่แก้เป็น 10.x หรือ 172.16.x ควรออกผ่านอุโมงค์องค์กร และที่อยู่สาธารณะที่ไม่มีคำนำหน้าที่ตรงกันควรใช้เส้นทางเริ่มต้นที่เหลืออยู่ หากทั้งสองบรรทัดระบุทางออกเดียวกัน การแยกไม่ได้ทำสิ่งที่เอกสารอธิบาย

จดสองโฟลว์และทดสอบแต่ละอัน

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

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