Android 12 กับ IKEv1 VPN: เวอร์ชันเปิดตัว, IKEv2, แอปจากบุคคลที่สาม

โทรศัพท์สองเครื่องรายงาน Android 12 ในหน้าตั้งค่าทั้งคู่ และมีเพียงเครื่องเดียวที่ยังเริ่มโปรไฟล์ IPsec XAuth เก่าที่เกตเวย์ของคุณเสนอ ความต่างไม่ใช่การตั้งค่าที่ผู้ใช้เข้าถึงได้: กลไกป้องกันที่กั้นเส้นทาง IKEv1 แบบเก่าภายในจะดูระดับ SDK ที่อุปกรณ์มาพร้อม ไม่ใช่แค่รุ่นที่ใช้งานอยู่ตอนนี้ รายละเอียดเดียวนี้ตัดสินว่าการเปรียบเทียบทั้งฟลีตมีความหมายหรือไม่ และยังตัดสินว่าเส้นทางย้ายระบบสามเส้นทางที่คุณต้องการจริงคือเส้นไหน

โทรศัพท์ Android 12 สองเครื่องไม่ใช่กรณีทดสอบเดียวกัน

การเปลี่ยนแปลงใน AOSP ที่หยุดอุปกรณ์ใหม่ไม่ให้เริ่มโปรไฟล์ IKEv1 แบบเก่าเปรียบเทียบ DEVICE_INITIAL_SDK_INT กับ Android S ซึ่งคือ API 31 ในเส้นทางเริ่มต้นแบบเก่าภายใน โปรไฟล์ที่เข้าเกณฑ์จะทำให้เกิดความล้มเหลวในการดำเนินการที่ไม่รองรับก่อนจะมีการเชื่อมต่อที่เป็นประโยชน์ใด ๆ โทรศัพท์ที่มาพร้อม Android 11 และอัปเดตภายหลังยังผ่านกลไกนั้นได้ รุ่นที่เปิดตัวพร้อม Android 12 ไม่ผ่าน

คุณอ่านตัวเลขสองค่านี้ได้บนอุปกรณ์ที่เปิดการดีบัก:

adb shell getprop ro.product.first_api_level
adb shell getprop ro.build.version.sdk
adb shell getprop ro.build.version.release

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

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

เส้นทางที่หนึ่ง: เก็บสแตกเก่าภายในไว้ที่ที่ยังทำงานอยู่

สแตกเก่าคือตัวที่อ่านโปรไฟล์ IPsec XAuth PSK, IPsec Hybrid RSA และ L2TP/IPsec PSK จากหน้าจอ VPN ของระบบ บนอุปกรณ์ที่มาพร้อมต่ำกว่า API 31 มันยังเป็นเส้นทางที่เป็นไปได้หลังอัปเกรด นั่นคือเหตุผลที่การนำร่องบนเครื่องเก่าอาจสำเร็จ ในขณะที่เครื่องใหม่ปฏิเสธโปรไฟล์เดียวกัน

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

เส้นทางที่สอง: โปรไฟล์ IKEv2 ของแพลตฟอร์ม

รูปแบบการจัดเตรียมสาธารณะของ Android สำหรับ IKEv2 เป็นออบเจ็กต์อีกชนิด ไม่ใช่โปรไฟล์ IKEv1 ที่เปลี่ยนชื่อ API ของแพลตฟอร์มสำหรับโปรไฟล์ IKEv2 มาพร้อม API 30 และคาดหวัง IKEv2 ด้วยวิธีการพิสูจน์ตัวตนที่เกตเวย์เสนอ ซึ่งมักอิงใบรับรองหรือ EAP ไม่มีการอัปเกรดที่เข้ากันได้ระดับสายจาก IKEv1 XAuth หรือ Hybrid ไปเป็น IKEv2: เกตเวย์ต้องถูกกำหนดค่าสำหรับโปรโตคอลใหม่ และโปรไฟล์ต้องมีตัวตนที่ตรงกัน

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

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

เส้นทางที่สาม: แอปไคลเอนต์จากบุคคลที่สาม

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

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

ทางเลือกขึ้นกับสิ่งที่เกตเวย์เสนอได้

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

สองจุดทำให้แผนป้องกันได้ ข้อแรก บันทึกเหตุผลของแต่ละข้อยกเว้นพร้อมรุ่นและระดับเปิดตัว เพื่อให้ผู้ตรวจสอบเห็นว่าเส้นแบ่งคือกลไกป้องกันของแพลตฟอร์ม ไม่ใช่ความชอบที่ไม่ได้อธิบาย ข้อที่สอง ให้ถือการย้ายระบบเป็นงานที่วางแผนไว้: IKEv1 ถูกยกเลิกตามเส้นทางมาตรฐาน (RFC 9395) ซึ่งหมายความอุปกรณ์ที่เหลือจะลดลงเรื่อย ๆ และข้อยกเว้นควรสิ้นสุดไปพร้อมกัน