กฎโดเมนของ Apple VPN On Demand เปิดอุโมงค์อย่างไร
กฎโดเมนตัดสินใจเพียงว่าเมื่อใดอุโมงค์จะเปิด การตรวจสอบ DNS แบบ connect-if-needed ทำงานอย่างไร ทำไมเส้นทางยังเลือกทราฟฟิก และวิธีทดสอบโปรไฟล์
อุโมงค์จะเปิดเมื่อคุณขอชื่อภายในหนึ่งชื่อ และยังคงปิดอยู่เมื่อแอปถัดไปต้องการมันมากพอ ๆ กัน นี่ไม่ใช่บั๊กในแอป แต่เป็นรูปร่างของกฎโดเมน การกำหนดค่า on-demand ของ Apple อธิบายเงื่อนไขในการสร้างการเชื่อมต่อ และรูปแบบโดเมนของเงื่อนไขเหล่านั้นถามตัวแก้ไขชื่อของระบบก่อนที่แพ็กเก็ตเดียวจะเคลื่อนที่ คำถามสองข้อมักถูกสับสนเสมอ: อุโมงค์ควรขึ้นเมื่อใด และอุโมงค์บรรทุกอะไรเมื่อมันมีอยู่แล้ว ข้อแรกคือทริกเกอร์ ข้อที่สองคือนโยบายเส้นทางและตัวแก้ไขชื่อ และโปรไฟล์หนึ่งมักตั้งค่าทั้งสองใน payload เดียวกัน ดังนั้นกฎโดเมนที่ถูกต้องก็ยังอาจทำให้คุณอยู่ในเครือข่ายผิดได้
ทริกเกอร์และการเลือกทราฟฟิกอยู่คนละชั้น
กฎ on-demand อาศัยอยู่ในพจนานุกรม on-demand ของ payload VPN: รายการกฎที่เรียงลำดับ แต่ละข้อมีแอ็กชันและชุดเงื่อนไขการจับคู่ ระบบจะประเมินเมื่อการเชื่อมต่อเปลี่ยนหรือเมื่อมีบางอย่างพยายามเข้าถึงเครือข่าย และแอ็กชันตัดสินว่าจะยกอุโมงค์ขึ้น ประเมิน ตัดการเชื่อมต่อ หรือเพิกเฉย ทั้งหมดนี้เกิดขึ้นในชั้นเครือข่ายของแพลตฟอร์ม ก่อนที่แอปของคุณจะมีซ็อกเก็ต
สิ่งถัดมาคือกลุ่มคีย์แยกต่างหาก: การตั้งค่า IPv4 และ IPv6 ของอุโมงค์ เส้นทางที่รวมและยกเว้น ที่อยู่เซิร์ฟเวอร์ DNS และบน iOS และ iPadOS การแมปตามแอปที่ตัดสินว่าแอปใดใชุ้โมงค์ได้ โปรไฟล์สามารถจับคู่ทริกเกอร์กว้างกับเส้นทางแคบ หรือทริกเกอร์แคบกับเส้นทางเริ่มต้น อ่านเพียงครึ่งเดียวและอีกครึ่งจะดูเหมือนความผิดปกติ
ฉันมีโปรไฟล์ห้องแล็บที่เชื่อมต่อทุกครั้งที่มีการขอสิ่งที่อยู่ใต้โดเมนภายใน แต่กำหนดเส้นทางเพียง /16 เดียวเข้าอุโมงค์ มันทำตามที่ payload บอกอย่างแม่นยำ และยังเป็นโปรไฟล์ชนิดที่สร้างตั๋ว 지원: ผู้คนคิดว่าอุโมงค์ที่เชื่อมต่อหมายถึงทราฟฟิกของพวกเขาอยู่ข้างใน
กฎโดเมนถามอะไรตัวแก้ไขชื่อจริง ๆ
รูปแบบโดเมนของกฎ ซึ่งมักเรียกว่า connect-if-needed ไม่ได้ตรวจสอบ payload ของแพ็กเก็ตหรือเฝ้าดู URL เมื่อชื่อถูกแก้ ระบบจะเปรียบเทียบกับโดเมนในกฎ และเมื่อตรงกันจะถามว่าชื่อนั้นแก้ได้ผ่านเซิร์ฟเวอร์ DNS ที่อุโมงค์ให้มาหรือไม่ หากตัวแก้ไขชื่อของอุโมงค์ตอบ ชื่อนั้นถือเป็นภายในและการเชื่อมต่อเริ่มต้น หากตัวแก้ไขชื่อภายในตอบแทน ชื่อนั้นถือเป็นภายนอกและไม่มีอุโมงค์ปรากฏ ภาพรวมการติดตั้งใช้งานของ Apple อธิบายสิ่งนี้ว่าเป็นการตรวจจับเครือข่ายตามด้วยการประเมินการเชื่อมต่อ
ผลที่ตามมาสองประการ ประการแรก โปรไฟล์ต้องระบุเซิร์ฟเวอร์ DNS ภายในอุโมงค์ กฎโดเมนที่ไม่มีตัวแก้ไขชื่อของอุโมงค์ไม่มีอะไรให้เปรียบเทียบ ดังนั้นการประเมินจึงไม่สามารถให้การจับคู่ที่คุณคาดหวังได้ ประการที่สอง การค้นหาต้องไปถึงตัวแก้ไขชื่อของระบบ แอปหรือเบราว์เซอร์ที่รัน DNS แบบเข้ารหัสของตัวเอง ส่วนขยายที่ตอบในเครื่อง หรือการเชื่อมต่อกับที่อยู่ตามตัวอักษรไม่เคยสร้างการแก้ชื่อที่กฎรออยู่ บ่ายที่ยาวนานที่สุดบ่ายหนึ่งของฉันจบลงเมื่อพบว่าลูกค้าที่อยู่หน้าอุโมงค์ใช้ DNS over HTTPS
แคชก็ลบทริกเกอร์ออกไปด้วย ชื่อที่มีอยู่ในแคชแล้วอาจถูกตอบโดยไม่มีการตรวจสอบที่จะเริ่มอุโมงค์ ดังนั้นกฎที่ใช้ได้เมื่อวานจะล้มเหลวหลังรีบูต หรือหลังจากอุโมงค์ขึ้นมาระยะหนึ่ง บน macOS sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder รีเซ็ตสถานะ บน iOS การเปิดและปิดโหมดเครื่องบินหรือรีสตาร์ตอุปกรณ์ให้จุดเริ่มต้นที่สะอาดเทียบเท่ากัน
ขอบเขตการจับคู่: ชื่อ แอป และเครือข่าย
การจับคู่โดเมนเป็นประเภทหนึ่งในหลายประเภท กฎยังสามารถจับคู่ประเภทอินเทอร์เฟซ (Wi-Fi, เซลลูลาร์, Ethernet) และ SSID ที่ระบุ และรายการตามแอปหรือโดเมน Safari ผูกอุโมงค์กับเวิร์กโฟลว์เดียว การผูกนี้ธิบายประสบการณ์แปลก ๆ ที่มีเพียงแอปเดียวทำงานต่างจากอย่างอื่น: แอปอื่นอยู่นอกขอบเขตของอุโมงค์ จึงยังใช้เส้นทางภายในเครื่องแม้ไอคอนอุโมงค์จะบอกว่าเชื่อมต่อแล้ว
ลำดับสำคัญกว่าที่ผู้คนคาดคิด กฎถูกประเมินตามลำดับและข้อแรกที่ตรงกันให้แอ็กชัน ดังนั้นกฎกว้างเชื่อมต่อบน Wi-Fi ใดก็ได้ที่วางเหนือกฎโดเมนแคบจะชนะอย่างเงียบ ๆ และทำให้กฎโดเมนทดสอบไม่ได้ ก่อนเขียนรายการโดเมนใหม่ ให้ยืนยันว่าไม่มีกฎก่อนหน้านี้ตรงกันอยู่แล้ว
นี่คือเหตุผลที่ always-on ไม่ใช่เพียงกฎ on-demand ที่เข้มงวดกว่า การบังคับใช้ always-on เป็นโหมดการติดตั้งใช้งานแยกต่างหาก ที่มีข้อกำหนดการกำกับดูแลและการจัดการของตัวเอง มันเปิดอุโมงค์ไว้แทนที่จะตอบสนองต่อชื่อ หากสิ่งที่คุณต้องการคืออุโมงค์ที่ไม่ล้มเหลวเลย กฎโดเมนคือเครื่องมือที่ผิด
รูปแบบความล้มเหลวที่เลียนแบบกฎที่เสีย
รายงานส่วนใหญ่ว่ากฎโดเมนใช้ไม่ได้ตกอยู่ในหนึ่งในห้าจุด และมีเพียงจุดสุดท้ายเท่านั้นที่เป็นข้อความของกฎ
| What you see | Layer | First check |
|---|---|---|
| Tunnel comes up, internal site still fails | route or resolver after connect | netstat -rn, scutil --dns |
| Tunnel never comes up for that name | trigger path | fresh lookup, cache flush, private DNS |
| Tunnel comes up for every app | scope, or an earlier rule | rule order, per-app mapping |
| Tunnel drops and will not return on the same Wi-Fi | interface or SSID match, admission | captive portal, SSID string, auth prompt |
| Tunnel returns after you disconnect it | profile ownership | profiles show |
พอร์ทัล captive สมควรมีบรรทัดของตัวเอง เพราะ Wi-Fi ในโรงแรมและสนามบินดักจับการค้นหาที่กฎพึ่งพาอยู่พอดี จนกว่าพอร์ทัลจะรับอุปกรณ์ เซิร์ฟเวอร์ DNS ของอุโมงค์เข้าถึงไม่ได้ การตรวจสอบล้มเหลว และความล้มเหลวดูเหมือนโดเมนที่สะกดผิด การพิสูจน์ตัวตนเป็นอีกกรณีที่เงียบ: กฎอาจทำงาน อุโมงค์อาจเริ่มเชื่อมต่อ และการเชื่อมต่อตายเพราะใบรับรองหมดอายุหรือพรอมต์ที่ปรากฏบนจออื่น
IPv6 สร้างรูปแบบที่วินิจฉัยผิดได้ง่าย ชื่อที่มีทั้งสองตระกูลที่อยู่อาจถูกตอบจากระเบียน AAAA ก่อน ในขณะที่รายการเส้นทางของอุโมงค์บรรทุกเพียง IPv4 เบราว์เซอร์หนึ่งสำเร็จ อีกตัวล้มเหลว และรายการโดเมนไม่มีความผิดเลย
ทดสอบด้วยคำขอจริง ตามลำดับนี้
อ่านนโยบายก่อนเดา บน macOS sudo profiles show -type configuration พิมพ์โปรไฟล์ที่ติดตั้งรวมถึง payload VPN scutil --nc list แสดงสถานะบริการ และ scutil --nc show <service> พิมพ์พจนานุกรม on-demand ที่ระบบใช้ บน iPhone หรือ iPad ที่มีการจัดการ payload เดียวกันมาจากคอนโซลการจัดการหรือรายงาน MDM บันทึกเครือข่ายมีให้ใช้ด้วย log stream --predicate 'subsystem == "com.apple.networkextension"' บน macOS และผ่านคอนโซลอุปกรณ์เมื่อเชื่อมต่อโทรศัพท์
จากนั้นทดสอบด้วยชื่อโฮสต์ที่ยังไม่ถูกถามก่อนหน้าในเซสชันนี้ เลือกชื่อในโซน DNS ของอุโมงค์ที่คุณรู้ว่าแก้ภายในได้ ขอหนึ่งครั้ง และดูว่าอุโมงค์ปรากฏหรือไม่ เรียกใช้การค้นหาเดิมสองครั้ง: ความพยายามครั้งที่สองฝึกเส้นทางแคช และความแตกต่างระหว่างสองครั้งบอกคุณว่าทริกเกอร์คือการแก้ชื่อหรือการกำหนดเส้นทาง
เมื่ออุโมงค์ขึ้นแล้ว ให้ตรวจสอบสองชั้นแยกกัน netstat -rn -f inet และ netstat -rn -f inet6 แสดงว่าแต่ละคำนำหน้าชี้ไปที่ใด scutil --dns แสดงลำดับตัวแก้ไขชื่อและอินเทอร์เฟซใดเป็นเจ้าของตัวแก้ไขชื่อแต่ละตัว และ nettop -m route แสดงอินเทอร์เฟซใดบรรทุกไบต์ หากอุโมงค์ขึ้นและตัวแก้ไขชื่อถูกต้องแต่ทรัพยากรยังล้มเหลว ให้หยุดแก้ไขกฎ ตรวจสอบการอนุญาตฝั่งเซิร์ฟเวอร์และเส้นทางขากลับ
เมื่อกฎเป็นของคนอื่น
หากอุโมงค์ปรากฏอีกครั้งหลังจากคุณตัดการเชื่อมต่อ กฎมักเป็นของโปรไฟล์ไม่ใช่แอป: การกำหนดค่าที่ถูกผลักผ่าน MDM โปรไฟล์ส่วนตัวที่หลงเหลือ หรือโปรไฟล์ที่ติดตั้งโดยไคลเอนต์อื่น sudo profiles show -type configuration และการค้นหาคีย์ on-demand จะจำกัดขอบเขตลง และ เส้นทางการลบคือโปรไฟล์ ไม่ใช่สวิตช์ในแถบเมนู การลบรายการบริการหรือแอปจะทิ้งกฎไว้ และการติดตั้งครั้งถัดไปจะสืบทอดมันอีกครั้ง
การทดสอบครั้งเดียวตัดสินความเป็นเจ้าของ: ตัดการเชื่อมต่อ รอ ขอชื่อภายในอีกครั้ง หากอุโมงค์กลับมา ทริกเกอร์ทำงานตามที่ออกแบบ และคำถามที่เปิดอยู่คือใครจัดการมันและขอบเขตนั้นคือสิ่งที่คุณต้องการหรือไม่
ก่อนรายงานสิ่งนี้เป็นบั๊ก ให้ทำการตรวจสอบห้าข้อเดิม: ที่อยู่ตัวแก้ไขชื่อของอุโมงค์มีอยู่ใน payload ชื่อที่ไม่ได้ถูกแคช ไม่มีกฎก่อนหน้าที่ตรงกันอยู่แล้ว เส้นทาง AAAA ที่รายการเส้นทางครอบคลุม และแอปอยู่ในขอบเขตของอุโมงค์ เมื่อทั้งห้าข้อเป็นจริง กฎกำลังทำหน้าที่ของมัน และข้อบกพร่องอยู่ไกลออกไปตามเส้นทาง