iPhone Always On VPN: อุโมงค์สองอุโมงค์ใช้ IP เสมือนหนึ่งเดียวร่วมกันได้

บน iPhone ที่ถูกกำกับดูแลพร้อมโปรไฟล์ Always On ที่จัดการอยู่ โทรศัพท์จะถืออุโมงค์สำหรับแต่ละอินเทอร์เฟซ IP ที่ใช้งานอยู่ ดังนั้นเซลลูลาร์และ Wi-Fi ต่างก็ได้ของตัวเอง จากนั้นเซิร์ฟเวอร์จะแสดงสมาคมความปลอดภัย IKE สองรายการสำหรับอุปกรณ์เดียว มักใช้ที่อยู่เสมือนหนึ่งเดียวร่วมกัน และแรงกระตุ้นแรกคือเรียกสิ่งนี้ว่าวงจร rekey แล้วเริ่มเปลี่ยนตัวจับเวลา แรงกระตุ้นนั้นมักผิด ให้ทำตามขั้นตอนด้านล่างตามลำดับที่หลักฐานปรากฏบนเซิร์ฟเวอร์ และอย่าแตะการตั้งค่าโทรศัพท์จนกว่าเซิร์ฟเวอร์จะบอกคุณว่าคุณอยู่ในกรณีใด

เริ่มจากสองแถวที่เซิร์ฟเวอร์มีอยู่แล้ว

แสดงรายการสมาคมด้วย swanctl --list-sas และอ่านสี่ฟิลด์ในทั้งสองรายการ คือที่อยู่ระยะไกล อัตลักษณ์ที่ผ่านการพิสูจน์ตัวตน IP เสมือนที่จัดสรรให้ และเวลาที่สร้าง ที่อยู่ภายนอกสองที่ที่แตกต่างกันพร้อมอัตลักษณ์หนึ่งและ IP เสมือนหนึ่งคือรูปแบบที่เริ่มคำถามนี้ และควรจดไว้ก่อนการเปลี่ยนแปลงใด ๆ จากนั้นตรวจสอบสมาคมลูกที่ผูกกับแต่ละรายการ เพราะตัวเลือกทราฟฟิกเป็นตัวกำหนดว่าการค้นหาปลายทางจะแยกอุโมงค์สองอุโมงค์ได้หรือไม่ คู่ที่ปรากฏและหายไปในไม่กี่วินาทีเป็นสัตว์อีกชนิดหนึ่งจากคู่ที่ทั้งสองอยู่ได้หลายชั่วโมง

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

ตัดสินว่าคุณกำลังดูการซ้อนทับแบบใด

rekey ของ IKEv2 และการพิสูจน์ตัวตนซ้ำแบบ make-before-break สร้างการซ้อนทับสั้น ๆ โดยเจตนา ด้วยการสร้างสมาคมใหม่ก่อนลบอันเก่า การประทับเวลาเป็นตัวชี้ขาด เพราะ SA เก่าที่หายไปหนึ่งหรือสองวินาทีหลังตัวใหม่ปรากฏคือการต่ออายุที่ทำงานของมัน อุโมงค์อินเทอร์เฟซที่เป็นอิสระไม่เคยมีลักษณะเช่นนั้น เพราะแต่ละอันคงอยู่ตราบที่อินเทอร์เฟซของมันยังทำงาน และการลบอันหนึ่งไม่ได้เกิดจากการสร้างอีกอัน

พฤติกรรม Always On ที่จัดการโดย Apple เป็นรายอินเทอร์เฟซ จึงเป็นเหตุให้อุปกรณ์ที่ถูกกำกับดูแลดูยุ่งกว่าที่กำหนดค่าไว้ด้วยมือได้อย่างชอบธรรม สวิตช์เชื่อมต่ออัตโนมัติของแอปผู้ให้บริการไม่ได้หมายความเช่นเดียวกัน และกฎ on-demand ทั่วไปก็ไม่เช่นกัน ภาพรวมการปรับใช้ของ Apple อธิบายรูปแบบรายอินเทอร์เฟซ เปรียบเทียบสองแถวของคุณกับมันก่อนสันนิษฐานว่าเป็นวงจร ทั้งสองรูปแบบดึงจากพูลฝั่งเซิร์ฟเวอร์เดียวกัน การซ้อนทับจึงเป็นสัญญาณแรกเพียงอย่างเดียวของคุณ

ดูว่าทำไมที่อยู่เสมือนหนึ่งเดียวสำหรับสองอุโมงค์จึงทำให้คำตอบเสีย

คำตอบถึงโทรศัพท์ถูกส่งไปยังที่อยู่ภายใน และเคอร์เนลเลือกอุโมงค์ขาออกตามปลายทางและนโยบาย ไม่ใช่ตามอินเทอร์เฟซที่โทรศัพท์ใช้ สมาคมสองรายการที่เกิดขึ้นพร้อมกันและถือ IP เสมือนเดียวกันด้วยนโยบายที่ตรงกันทำให้การตัดสินใจเส้นทางไม่มีทางบอกว่าคำตอบเป็นของเซสชันใด คำตอบบางส่วนไปผิดอุโมงค์ และโทรศัพท์แสดงการเชื่อมต่อที่ทำงานได้ทางเดียวหรือตายเมื่อ Wi-Fi ขึ้น ผลลัพธ์คำสั่งสองรายการพิสูจน์สถานะ swanctl --list-sas แสดง IP เสมือนเดียวกันบน SA ทั้งสอง และ ip xfrm policy แสดงตัวเลือกที่เหมือนกันสองตัว

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

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

เปลี่ยนพูลหรือรูปแบบการทำงานพร้อมกัน ไม่ใช่ตัวจับเวลา rekey

ในการกำหนดค่า swanctl ความเป็นเอกลักษณ์เป็นนโยบายที่ชัดเจนบนการเชื่อมต่อ unique = replace ลบการเชื่อมต่อที่เก่ากว่าเมื่อมีการสร้างอันใหม่ และ unique = keep ปฏิเสธผู้มาใหม่ ค่าทั้งสองมีผลเมื่อตั้งค่าการเชื่อมต่อ ไม่ใช่กับ SA ลูกภายใน

connections {
  ios-alwayson {
    unique = replace
  }
}

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

ทดสอบการเปลี่ยนผ่านที่คุณปรับใช้จริง

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

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