ระบบอัตโนมัติ L2TP บน Android: สคริปต์ขอได้ แต่สร้างไม่ได้
เส้นทาง shell ไม่ได้ยก L2TP/IPsec บน Android IPsec, L2TP, PPP และนโยบายแพลตฟอร์มต่างมีส่วนของตน ดังนั้นเลือกว่าอะไรควบคุมได้
ความเชื่อผิดคือ L2TP บน Android เป็นอีกสิ่งหนึ่งที่สคริปต์ shell เริ่มได้: เพิ่มเส้นทาง เรียกบริการเก่า จบ แต่เป็นไปไม่ได้ เพราะสี่ชั้นที่ต่างกันต้องตกลงกันก่อนที่อุโมงค์จะบรรทุกแพ็กเก็ต ชั้น IPsec ปกป้องเส้นทาง L2TP บรรทุกเซสชัน PPP เจรจาลิงก์ และ Android ต้องลงทะเบียนผลลัพธ์เป็น VPN ที่มันกำหนดเส้นทางรอบได้ ผมเคยเห็นความพยายามนี้สองครั้งด้วยคำสั่งที่คัดลอกมา และทั้งสองครั้งเส้นทางมีอยู่ขณะที่ไม่มีอะไรถูกเข้ารหัส
การเปลี่ยนเส้นทางทำอะไรได้จริง
การเพิ่มเส้นทางตัดสินว่าแพ็กเก็ตจะไปไหนต่อไป มันไม่เจรจาสมาคมความปลอดภัย ไม่เปิดเซสชัน L2TP และไม่รันการแลกเปลี่ยน PPP ที่สร้างที่อยู่ เพื่อนร่วม และการตั้งค่า DNS บนโทรศัพท์ผลลัพธ์ที่มองเห็นคือทราฟฟิกที่ออกผิดเส้นทาง หรือออกไปแล้วตาย โดยไม่มีสถานะอุโมงค์ที่ไหนเลย
เช่นเดียวกันกับการเรียกบริการที่คัดลอกจากรุ่นเก่า การวางท่อ VPN ภายในของ Android ไม่ใช่ API ระบบอัตโนมัติที่เผยแพร่ และทรานแซกชันที่มีหมายเลขจากอีกเวอร์ชันอาจไปโดนการดำเนินการอื่นหรือต้องการสิทธิ์ที่สคริปต์ไม่มี ระบบอัตโนมัติที่พกพารหัสผ่านไม่ควรพึ่งพาอาร์กิวเมนต์ภายในที่เดาเอา เพราะโหมดล้มเหลวคือ no-op เงียบ ๆ หรือโปรไฟล์ที่สร้างครึ่งเดียวซึ่งไม่มีใครเก็บกวาด
เจ้าของสี่ราย และสคริปต์ไม่ใช่สักราย
รับพวกเขาตามลำดับ IPsec สร้างและดูแลเส้นทางที่ป้องกันและตรวจสอบเพื่อนร่วม L2TP บรรทุกเซสชันเหนือมัน และการแบ่งชั้นนี้คือเหตุผลที่มาตรฐานปฏิบัติต่อทั้งสองเป็นกลไกแยกกันไม่ใช่โปรโตคอลเดียว ภายในนั้น PPP เจรจาพารามิเตอร์ลิงก์ที่ไคลเอนต์จะใช้ จากนั้น Android เป็นเจ้าของฝั่งแพลตฟอร์ม: อินเทอร์เฟซ VPN ที่ลงทะเบียน ขอบเขตต่อแอป สถานะ always-on และวงจรชีวิตที่ตัดสินว่าเกิดอะไรขึ้นเมื่อแอปถูกฆ่า
สคริปต์เห็นได้เพียงชั้นสุดท้าย และมักเป็นทางอ้อม มันขอให้ไคลเอนต์เชื่อมต่อได้หากไคลเอนต์นั้นเปิดเผยการควบคุมที่มีเอกสาร และจากนั้นสามารถเฝ้าดูสถานะอินเทอร์เฟซได้ มันแทนสามชั้นล่างไม่ได้ และทำให้แพลตฟอร์มถือว่าอินเทอร์เฟซที่ไม่ได้ลงทะเบียนเป็น VPN ไม่ได้
ทำไมเดมอนก็ไม่ใช่ทางลัด
การเริ่มเดมอน Linux ที่มีสิทธิพิเศษบนอุปกรณ์ดูเหมือนชิ้นส่วนที่หายไป และบ่อยครั้งมันยกอุโมงค์ขึ้นจริง สิ่งที่มันไม่ทำคือลงทะเบียนอุโมงค์นั้นกับ Android อินเทอร์เฟซมีอยู่ในเคอร์เนล แต่การเลือก VPN ของแพลตฟอร์ม การกำหนดเส้นทางต่อแอป นโยบาย always-on และวงจรชีวิตไม่รู้จักมัน และการเปลี่ยนเส้นทางกับ DNS ของเดมอนเองก็แข่งขันกับตัวจัดการเครือข่ายในตารางเดียวกัน
ผลลัพธ์คือการเชื่อมต่อที่ทำงานกับทราฟฟิกของเดมอนและอย่างลึกลับไม่ทำงานกับแอปที่คุณใส่ใจ หรือการเชื่อมต่อที่อยู่รอดจนระบบประเมินเครือข่ายใหม่ ไม่ว่าผลลัพธ์ใดก็ไม่ใช่บั๊กของแพลตฟอร์ม นี่คือเส้นแบ่งระหว่างการเป็นเจ้าของซ็อกเก็ตและการเป็นเจ้าของสิ่งอำนวยความสะดวก VPN
เส้นทางที่รองรับหน้าตาเป็นอย่างไร
หากองค์กรย้ายไปยังโปรไฟล์ที่ Android จัดหาเองได้ เส้นทางแพลตฟอร์มคือทางที่ซื่อตรง จาก API 30 VpnManager รองรับการจัดหาและการควบคุมโปรไฟล์ VPN ของแพลตฟอร์มโดยแอป พร้อมขั้นตอนการอนุญาตที่ผูกกับแอปที่เรียกใช้ มันไม่ใช่ตัวแปลง L2TP: โมเดลโปรไฟล์ที่จัดหาสำหรับ IKEv2 ไม่แปลการกำหนดค่า L2TP ที่มีอยู่ และการเปลี่ยนโปรโตคอลคือการย้าย ไม่ใช่การเปลี่ยนชื่อ ข้อมูลประจำตัว เส้นทาง DNS ส่วนตัว และสิทธิ์การเข้าถึงต้องถ่ายโอนอย่างตั้งใจ
หากบริการต้องคงเป็น L2TP/IPsec ชุดค่าผสมที่รองรับคือไคลเอนต์และรุ่น OS ที่ผู้ให้บริการบันทึกไว้จริง และสัญญาระบบอัตโนมัติของมันหากมี เมื่อไม่มีการควบคุมที่ไม่มีผู้ดูแลซึ่งมีเอกสาร คำตอบที่ถูกต้องคือการเชื่อมต่อแบบแมนนวลที่รองรับ ไม่ใช่สคริปต์ที่มีสิทธิพิเศษเปราะบางซึ่งบังเอิญทำงานบนบิลด์เดียว
ระบบอัตโนมัติที่ถูกต้องทำอะไร
เมื่อมีการควบคุมที่มีเอกสาร ระบบอัตโนมัติมีงานเล็กและป้องกันได้: ขอการเชื่อมต่อที่ระบุชื่อ รอความพร้อม หยุดเมื่อการพิสูจน์ตัวตนหรือการตั้งค่าล้มเหลว รันภาระงานที่ตั้งใจ และปล่อยการล้างให้ส่วนประกอบที่เป็นเจ้าของการเชื่อมต่อ ข้อมูลรับรองอยู่กับไคลเอนต์ที่รู้วิธีจัดเก็บและหมุนเวียน
จดว่าส่วนประกอบใดเป็นเจ้าของชั้นใดก่อนเขียนบรรทัดแรก และตรวจสอบผลลัพธ์กับสิ่งนั้น:
- IPsec และ PPP ได้รับการจัดการโดยไคลเอนต์ ไม่ใช่เส้นทางของสคริปต์
- การเชื่อมต่อปรากฏในสถานะ VPN ของแพลตฟอร์ม ดังนั้นขอบเขตต่อแอปและ always-on จึงใช้กับมัน
- ไม่มีการเรียกบริการภายใน หมายเลขทรานแซกชัน หรืออาร์กิวเมนต์ที่เดาเอาที่พกพาข้อมูลรับรอง
- ความล้มเหลวในขั้นตอนใดก็ตามไม่ทิ้งโปรไฟล์ที่ลงทะเบียนครึ่งเดียว