VPN รายแอปบน Android: การยกเว้นแอปไม่ใช่การบล็อกแอปนั้น

คนสองคนถามคำถามเดียวกันและได้คำตอบที่เข้ากันไม่ได้ เพราะพวกเขายืนอยู่คนละที่ คนหนึ่งเปิดหน้าจอการตั้งค่า VPN ของระบบอยู่และกำลังแก้ไขรายการแอป อีกคนกำลังเขียน VpnService.Builder.addDisallowedApplication() ในเอดิเตอร์ ทั้งคู่เรียกมันว่าตัวกรอง VPN รายแอป มีเพียงคนเดียวเท่านั้นที่เป็นเจ้าของการควบคุมที่เขาอธิบาย และทั้งคู่ไม่ได้บล็อกอะไรเลย

เริ่มจากหน้าจอที่ผู้ใช้เห็น

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

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

ตามแพ็กเก็ตเข้าไปในอุโมงค์

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

val builder = VpnService.Builder()
builder.addAddress("10.8.0.2", 32)
builder.addRoute("0.0.0.0", 0)
builder.addDisallowedApplication("com.example.bypass")
val tun = builder.establish()   // membership decided here

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

ทำไมการยกเว้นจึงดูเหมือนการบล็อก

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

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

อะไรพังเมื่อคุณสร้างมันเอง

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

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

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

ทดสอบด้วยแอปที่คุณควบคุม

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

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