ทำไมทราฟฟิกการดีบักไร้สายจึงไม่ใช่หลักฐานการรั่วไหลของ VPN

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

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

ตั้งชื่อสิ่งที่สังเกตก่อนตั้งชื่อบั๊ก

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

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

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

ทำไมสองเส้นทางจึงไม่เคยบรรจบกัน

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

ทราฟฟิกอินเทอร์เน็ตของแอปออกผ่านอินเทอร์เฟซอุโมงค์ที่ VpnService ติดตั้ง จับคู่ตาม UID และกฎการกำหนดเส้นทาง adbd เป็นเดมอนระบบที่ทำงานในฐานะผู้ใช้ shell ไม่ใช่แอปในชุดการกำหนดเส้นทางนั้น มันยังคงอยู่บนลิงก์ Wi-Fi ชั้นล่างแม้ทุกแอปจะถูกปักหมุดกับอุโมงค์

โหมดล็อกดาวน์บังคับใช้อุโมงค์กับแอปที่ครอบคลุม มันไม่ได้เปลี่ยนซ็อกเก็ตที่กำลังฟังให้เป็นเส้นทางออก

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

การทดสอบขาออกจริงมีหน้าตาอย่างไร

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

1. ยืนยันว่า VPN เป็นเส้นทางเดียว เปิด VPN แบบเปิดตลอดพร้อมบล็อกการเชื่อมต่อที่ไม่มี VPN
2. หยุด VPN ด้วยวิธีที่รองรับ และยืนยันว่าแอปรายงานว่าไม่มีการเชื่อมต่อ
3. ส่งคำขอที่ไม่เป็นอันตรายหนึ่งรายการจากแอปนั้น และสังเกตว่าล้มเหลวหรือสำเร็จ
4. ทำซ้ำโดยเปิดการดีบักไร้สาย แล้วปิด เพื่อแยกตัวแปร

คำขอที่ถูกบล็อกภายใต้เงื่อนไขเหล่านั้นเป็นหลักฐาน เซสชัน ADB ที่สำเร็จไม่ใช่ และ ping หนึ่งครั้งจากแอปเทอร์มินัลก็ไม่ใช่

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

การจับคู่มีอายุยืนกว่าเซสชัน

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

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

บนเครือข่ายที่ใช้ร่วมกันหรือไม่น่าเชื่อถือ ปล่อยให้ปิดไว้ การอนุญาตถาวรบนเครือข่ายที่คุณไม่ได้ควบคุมเป็นปัญหาที่ใหญ่กว่าการข้าม TUN ในเชิงสมมติ

ก่อนจะรายงานบั๊กนั้น

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

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

หากหลักฐานเดียวของคุณคือ ADB เชื่อมต่อขณะ VPN เปิดอยู่ คุณวัดผิดเส้นทาง ให้รันการทดสอบระดับแอปอีกครั้งก่อน คำตอบมักมาที่นั่น