แอปที่ถูกยกเว้นยังออนไลน์อยู่หรือไม่? กฎของแอปและเส้นทางต่างกัน
การยกเว้นแอป Android ออกจาก VPN ไม่ได้บล็อกแอปนั้น รายการอนุญาต กฎ UID และเส้นทางที่ส่งไปต่างกำหนดคนละส่วนของเส้นทาง
การยกเว้นแพ็กเกจเป็นคำสั่งกำหนดเส้นทาง ไม่ใช่การบล็อก ดังนั้นหน้าที่โหลดหลัง VPN เชื่อมต่อจึงเป็นสิ่งที่คาดไว้ ไม่ใช่หลักฐานของความล้มเหลว การยกเว้นนำแอปออกจากอุโมงค์แทนที่จะบล็อก และเครือข่ายปกติเป็นตัวขนส่งทราฟฟิกของแอปนั้น ที่นี่นโยบายสองชุดมาบรรจบกัน: ชุดหนึ่งเลือกโปรเซส อีกชุดเลือกปลายทาง. การอ่านตามลำดับนั้นอธิบายว่าทำไมไอคอนที่เชื่อมต่อกับแอปที่ทำงานอยู่จึงไม่ใช่ความขัดแย้ง
ทำไมการยกเว้นจึงทำให้เครือข่ายยังเปิดอยู่
VpnService.Builder รับรายการอนุญาตหรือรายการห้ามอย่างใดอย่างหนึ่ง ไม่รับทั้งสองอย่าง เฉพาะแพ็กเกจในรายการอนุญาตเท่านั้นที่ถูกกำหนดเส้นทางผ่านอุโมงค์ รายการห้ามกลับด้าน: ทุกแพ็กเกจยกเว้นที่ระบุไว้ใช้อุโมงค์ และที่ระบุไว้ยังคงใช้เส้นทางกายภาพ แพ็กเกจที่ไม่อยู่ในรายการอนุญาตก็อยู่นอกอุโมงค์ด้วย ดังนั้นการยกเว้นจึงเป็นสภาวะปกติของแอปส่วนใหญ่ในโหมดนั้น
สิ่งนี้ทำให้รายการห้ามภายในเป็นการตัดสินใจกำหนดเส้นทาง ไม่ใช่กฎไฟร์วอลล์ ถ้าข้อกำหนดคือการหยุดไม่ให้แอปเข้าถึงโฮสต์ อุโมงค์ต้องครอบคลุมแอปนั้น และเซิร์ฟเวอร์หรือนโยบายภายในต้องปฏิเสธทราฟฟิก การนำแอปออกจากอุโมงค์เปลี่ยนเพียงว่าอินเทอร์เฟซใดขนส่งแพ็กเกจของแอป
กรณี Play Store เป็นตัวอย่างที่จงใจทำโดยปกติ การยกเว้นแพ็กเกจของร้านค้าทำให้การดาวน์โหลดใช้การเชื่อมต่อพื้นฐานเมื่อทางออกของ VPN รบกวนการถ่ายโอน และแสดงว่าการยกเว้นหมายถึงการเลี่ยง ไม่ใช่การบล็อก
หนึ่งโปรไฟล์ หนึ่งรายการ
ตัวสร้างจะโยนข้อยกเว้นหากใช้ทั้งสองคำสั่ง ดังนั้นโปรไฟล์ที่อยู่ตรงหน้าคุณจึงเป็นรายการอนุญาตหรือรายการห้าม ข้อเท็จจริงเดียวนี้กำหนดวิธีอ่านทุกการสังเกตในภายหลัง ตรวจสอบโค้ดหรือการกำหนดค่าที่จัดการก่อนตารางกำหนดเส้นทาง เพราะรายการเป็นตัวกำหนดความหมายของเอาต์พุตที่เหลือ โปรไฟล์แบบผสมไม่ใช่สภาวะที่คุณจะมองดูได้
ความแตกต่างนี้ยังทำนายว่าแอปที่ติดตั้งใหม่จะทำอะไร ภายใต้รายการอนุญาตมันจะอยู่ข้างนอกจนกว่าจะมีคนเพิ่มเข้ามา ส่วนภายใต้รายการห้ามมันจะเข้าร่วมอุโมงค์โดยค่าเริ่มต้น
การกำหนดค่าที่จัดการแสดงตัวเลือกเดียวกันภายใต้ชื่อคีย์ที่ต่างกัน และคอนโซลบางตัวอธิบายว่าเป็นโหมด VPN ต่อแอปมากกว่ารายการ พฤติกรรมยังคงลดลงเหลือสองคำสั่งนั้น ดังนั้นตามการตั้งค่ากลับไปจนถึงรายการแพ็กเกจแทนที่จะเชื่อป้ายกำกับ หากป้ายกำกับกับรายการไม่ตรงกัน รายการชนะ
ตามกฎ UID ไปจนถึงตารางของอุโมงค์
Android ให้แต่ละแอปมี ID ผู้ใช้ Linux ของตัวเอง และบริการ VPN จะติดตั้งกฎนโยบายที่ตรงกับช่วง UID ทราฟฟิกที่ตรงกันจะถูกส่งไปยังตารางกำหนดเส้นทางที่เส้นทางเริ่มต้นชี้ไปที่อุปกรณ์ tun หมายเลขตารางถูกจัดสรรต่ออินสแตนซ์ VPN ดังนั้นจึงเปลี่ยนหลังการเชื่อมต่อใหม่หรือหลังสร้างโปรไฟล์ VPN ที่สอง
เอาต์พุตของกฎคือแผนที่ แต่ละบรรทัดระบุตารางค้นหา และตารางนั้นเก็บเส้นทางเริ่มต้นที่กำหนดว่าแพ็กเกจที่ตรงกันจะเข้าสู่อุโมงค์หรือไม่
adb shell ip rule show
adb shell ip route show table all
adb shell cmd package list packages -U | grep <package>รันคำสั่งที่สามก่อนเพื่อรับ UID จากนั้นหากฎที่มีช่วงครอบคลุมค่านั้น กฎนั้นชี้ไปที่หมายเลขตาราง และ ip route show table <n> ด้วยหมายเลขนั้นแสดงว่ามีเส้นทางเริ่มต้นผ่านอุปกรณ์ tun หรือไม่ หากตารางไม่มีเส้นทางเริ่มต้น แอปถูกเลือกแต่ไม่มีเส้นทาง ซึ่งเป็นความล้มเหลวอีกแบบ
คำสั่งเหล่านี้ต้องใช้บิลด์ที่แก้จุดบกพร่องได้หรืออุปกรณ์ที่ adb shell อ่านสถานะเครือข่ายได้ บนเครื่องที่ผลิตจริง ตัวจัดการแพ็กเกจยังตอบสนอง แต่การตรวจสอบเส้นทางอาจถูกปฏิเสธ ดังนั้นบันทึกเท่าที่ทำได้และถือส่วนที่เหลือว่ายังไม่ยืนยัน
เส้นทางอ้างสิทธิ์คำนำหน้า ไม่ใช่แอป
Builder.addRoute อ้างสิทธิ์คำนำหน้าปลายทางสำหรับอุโมงค์ 10.0.0.0/8 โปรไฟล์ที่เพิ่มเพียงอย่างเดียวจะส่งคำนำหน้านั้นผ่านอุโมงค์และปล่อยปลายทางอื่นทั้งหมดไว้บนเส้นทางกายภาพ นี่คือการทำอุโมงค์แบบแบ่งทั่วไป และไม่ขึ้นกับว่าแอปใดที่กฎเลือก
การกำหนดค่าที่เซิร์ฟเวอร์ส่งมาสะท้อนรูปแบบเดียวกัน การพุชเส้นทางแต่ละครั้งเพิ่มคำนำหน้า ขณะที่คำสั่ง redirect-gateway แทนที่เส้นทางเริ่มต้นและจับทุกอย่างสำหรับแอปที่อุโมงค์ครอบคลุม การลบคำสั่งนั้นอาจทำให้อุโมงค์ที่ทำงานอยู่หดเหลือซับเน็ตเดียวโดยไม่มีการเปลี่ยนแปลงใด ๆ บนอุปกรณ์
เส้นทางที่พุชมาพร้อมเกตเวย์หรือตัวคัดกรองเมตริกที่ผิดปกติอาจติดตั้งไม่สำเร็จด้วย ควรใช้รูปแบบคำนำหน้าธรรมดาและปล่อยให้เซิร์ฟเวอร์จัดการการส่งต่อและ NAT
อ่านส่วนตัดก่อนเปลี่ยนการตั้งค่า
อุโมงค์ขนส่งส่วนตัดของโปรเซสที่ครอบคลุมและปลายทางที่อ้างสิทธิ์ แอปที่ครอบคลุมซึ่งขอที่อยู่ภายนอกคำนำหน้าที่เผยแพร่จะออกผ่านเครือข่ายกายภาพ แพ็กเกจที่ถูกห้ามยังคงอยู่ข้างนอกแม้จะขอที่อยู่ภายในคำนำหน้าเหล่านั้น ไม่มีกรณีใดเป็นบั๊ก ทั้งสองคือสองนโยบายที่ทำงานของตน
VPN ต่อแอปอาจทิ้งแอปที่เชื่อมโยงไว้โดยไม่มีการเชื่อมต่อ เมื่อ on-demand ปิดอยู่และอุโมงค์ล่ม แอปยังคงผูกกับ VPN ต่อแอปและไม่มีทางสำรอง ซึ่งดูเหมือนแอปที่เสียมากกว่าสภาวะของนโยบาย การเปิด on-demand หรือการลบความเชื่อมโยงผ่านการจัดการเปลี่ยนแปลงสิ่งนั้น
| Layer | What it selects | Where to look | Typical mismatch |
|---|---|---|---|
| Package list | Processes | Builder calls or managed configuration | App excluded but expected to be blocked |
| UID policy rule | Which table a UID uses | ip rule show | Tunnel icon on, app still on Wi-Fi |
| Routing table | Destinations for matched traffic | ip route show table <n> | Covered app reaches only one subnet |
| Server push | Prefixes offered to the client | Server route configuration | Tunnel shrinks after a server edit |
วินิจฉัยทีละแกน พิสูจน์ยืนยันการอนุญาตหรือการห้ามก่อน อ่านกฎ UID และตารางที่ติดตั้งเป็นลำดับที่สอง และทดสอบแอปที่สองกับปลายทางเดียวกันเป็นลำดับสุดท้าย แอปที่สองแยกการเลือกโปรเซสจากการเลือกปลายทางในคำขอเดียว
จดผลลัพธ์เป็นแอป ปลายทาง และหมายเลขตาราง สามสิ่งนั้นคือสิ่งที่การเปลี่ยนแปลงครั้งถัดไปต้องรักษาไว้