ทำไมแอป Android ที่บล็อกไว้ยังแสดงการใช้เครือข่าย

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

ตัวนับวัดไบต์ ไม่ใช่การส่งถึง

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

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

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

การกำหนดนั้นตาม UID ไม่ใช่ไอคอน

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

เมื่อตัวเลขดูผิด ให้เทียบ UID ไม่ใช่ป้ายชื่อ API การใช้นั้นถูกถามด้วย UID และ adb shell dumpsys package <package> | grep userId= พิมพ์ตัวเลขที่ต้องเทียบ ดังนั้นสองรายการที่มี UID เดียวกันจึงเป็นตัวระบุเดียวกันจากมุมมองของตัวนับ

ช่วงเวลาอาจอยู่ก่อนกฎของคุณ

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

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

บริการ VPN อาจไม่ใช่ตัวที่คุณกำหนดค่าไว้

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

IPv4, IPv6 และ DNS ก็อาจแตกต่างกันได้ ตัวกรองที่จัดการ IPv4 อาจปล่อย IPv6 หรือตัวแปลง DNS ส่วนตัวไว้นอกขอบเขต ทำให้ทราฟฟิกบางส่วนของแอปเดินตามเส้นทางที่กฎของคุณไม่เคยอธิบาย ตรวจสอบว่าแอปใดเป็นเจ้าของ VPN อยู่ตอนนี้และรายการยกเว้นบอกอะไร ก่อนจะเขียนอะไรใหม่:

adb shell settings get secure always_on_vpn_app
adb shell dumpsys connectivity
adb shell dumpsys netstats detail

ทดสอบคำขอใหม่หนึ่งครั้งและบันทึกข้อเท็จจริงสี่ข้อ

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

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