แอป Android ไม่ยอมทำงานผ่าน VPN: ชั้นไหนเป็นตัวตัดสิน

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

ขั้นตอนที่ 1: รู้ว่าแอปปฏิเสธเมื่อใด

เวลาเป็นตัวแยกแยะแรก ล้างบัฟเฟอร์บันทึก ทำซ้ำความล้มเหลว แล้วดูว่าแอปทำอะไรก่อนที่จะบ่น:

adb logcat -c
# reproduce the failure in the app
adb logcat -d | grep -iE 'vpn|network|connect|http' | tail -60

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

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

ขั้นตอนที่ 2: อ่านมุมมองของโทรศัพท์เองต่อเครือข่าย

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

val cm = context.getSystemService(ConnectivityManager::class.java)
val caps = cm.getNetworkCapabilities(cm.activeNetwork)
val onVpn = caps?.hasTransport(NetworkCapabilities.TRANSPORT_VPN) == true

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

จากเวิร์กสเตชันคุณเห็นสถานะเดียวกันบนอุปกรณ์ทดสอบด้วย adb shell dumpsys connectivity และการมองหารายการเครือข่าย VPN เปรียบเทียบการรันที่อุโมงค์เปิดกับการรันที่ปิด แล้วเก็บผลลัพธ์ทั้งสองไว้

ขั้นตอนที่ 3: อ่านว่าเซิร์ฟเวอร์เห็นอะไรจริง ๆ

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

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

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

ขั้นตอนที่ 4: จับคู่หลักฐานกับหนึ่งในสามข้อสรุป

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

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

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

ขั้นตอนที่ 5: ใช้เส้นทางที่ได้รับการสนับสนุนและตรวจสอบ

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

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

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