การทำ tethering แบบย้อนกลับสำหรับ Android ผ่าน USB: คำสั่ง การตรวจสอบ และการย้อนกลับ
การทำ tethering แบบย้อนกลับส่งทราฟฟิกของโทรศัพท์ผ่านรีเลย์บนโฮสต์ สร้างเส้นทางจากโทรศัพท์ไปยังโฮสต์ คง VPN ของโฮสต์ไว้ในวงจร และตรวจสอบทุกช่วง
การทำ tethering แบบย้อนกลับย้ายทราฟฟิกของโทรศัพท์ไปยังคอมพิวเตอร์และส่งออกผ่านการเชื่อมต่อของคอมพิวเตอร์เครื่องนั้น สาย USB เพียงอย่างเดียวทำสิ่งนี้ไม่ได้ โทรศัพท์ต้องมีบริการดักจับที่รับช่วงการกำหนดเส้นทางของตน และคอมพิวเตอร์ต้องมีรีเลย์ที่พาแพ็กเก็ตเหล่านั้นต่อไป เส้นทางมีสี่ช่วง คือ แอปพลิเคชัน การดักจับบนโทรศัพท์ รีเลย์ USB และทางออกของโฮสต์ และแต่ละช่วงมีเจ้าของต่างกัน คู่มือนี้สร้างเส้นทางนั้น วาง VPN ของโฮสต์ไว้ในที่ที่ควรอยู่ และตรวจสอบทุกช่วงก่อนที่คุณจะเชื่อถือผลลัพธ์
ทำแผนที่ช่วงต่าง ๆ ก่อนรันสิ่งใด
แต่ละช่วงใช้แนวนโยบายของตัวเอง จึงไม่มีอะไรบอกได้ว่าเมื่อปลายหนึ่งทำงานได้ อีกปลายหนึ่งจะเป็นอย่างไร แอปพลิเคชันเลือกปลายทางและตัวแก้ไข ชื่อ บริการดักจับตัดสินว่าทราฟฟิกใดเข้าสู่รีเลย์ รีเลย์ส่งต่อไปยังซ็อกเก็ตของโฮสต์ และการกำหนดเส้นทางกับ VPN ของโฮสต์เป็นตัวตัดสินที่อยู่ซึ่งปลายทางเห็นในที่สุด
| Hop | Owner | What it decides |
|---|---|---|
| Application request | The app | Destination, resolver, address family |
| Capture service | Phone VpnService app | Which traffic enters the relay at all |
| ADB relay | Host process | Forwarding phone flows to host sockets |
| Host egress | Host routing and VPN | Exit address and host policy |
มีเพียงไคลเอนต์บริการ VPN หนึ่งรายเท่านั้นที่ถือบทบาทการดักจับของโทรศัพท์ได้ในแต่ละครั้ง แอป VPN ปกติตัวที่สองจึงไม่ซ้อนทับบนรีเลย์ ถ้า VPN เป็นของคอมพิวเตอร์ บริการดักจับคือข้อต่อการเข้าถึงไปยังคอมพิวเตอร์เครื่องนั้น ไม่ใช่หลักฐานว่า อุโมงค์ระยะไกลปกป้องผลลัพธ์อยู่แล้ว
เตรียมรีเลย์ให้พร้อมก่อนแตะโทรศัพท์
Gnirehtet เป็นตัวอย่างที่บันทึกไว้ของสถาปัตยกรรมนี้ คือ ไคลเอนต์บริการ VPN ที่ไม่ต้องใช้ root บนโทรศัพท์ พร้อมรีเลย์ที่ขนผ่าน ADB บนโฮสต์ และรองรับ TCP กับ UDP บน IPv4 คลังโค้ดของยังระบุว่า โครงการนี้ไม่ได้รับการดูแลอย่างแข็งขันอีกต่อไป จึงควรถือเป็นงานออกแบบอ้างอิงและเครื่องมือที่ใช้งานได้สำหรับห้องทดลอง ไม่ใช่ผลิตภัณฑ์ที่มีการสนับสนุนให้กำหนดเป็นมาตรฐานทั่วทั้งกองอุปกรณ์ที่บริหารจัดการ
adb devices
adb shell getprop ro.build.version.release
gnirehtet runรัน adb devices ก่อน โทรศัพท์ที่ยังไม่ยอมรับคีย์ดีบักของโฮสต์จะถูกรายงานว่าไม่ได้รับอนุญาต และรีเลย์จะไม่เชื่อมต่อจนกว่าจะมีการยอมรับข้อความบนอุปกรณ์ gnirehtet run ติดตั้งไคลเอนต์ เริ่มรีเลย์ และเปิดใช้งานการดักจับ ในเวอร์ชันที่แยกขั้นตอนออกจากกัน ให้ใช้คำสั่งย่อย install, relay และ start ที่บันทึกไว้แทน
การเข้าถึงผ่าน ADB เป็นความสัมพันธ์ของการควบคุมอุปกรณ์ ไม่ใช่การตั้งค่าเครือข่าย อนุญาตเฉพาะคอมพิวเตอร์ที่คุณควบคุม และวางแผนเพิกถอนการอนุญาตนั้นเมื่องานเสร็จ
นำ VPN ของโฮสต์กลับเข้าสู่เส้นทาง
รีเลย์เป็นกระบวนการปกติบนโฮสต์ การเชื่อมต่อต่อไปจึงเป็นไปตามตารางเส้นทางของโฮสต์ โปรไฟล์อุโมงค์เต็มจะพาไป ส่วนอุโมงค์แบบแยกอาจไม่พาไป ถ้า VPN ของโฮสต์ใช้การควบคุมรายแอป ให้เพิ่มไบนารีของรีเลย์ลงในชุดที่อนุญาต มิฉะนั้นรีเลย์จะยังใช้ส่วนเชื่อมต่อทางกายภาพต่อไปในขณะที่เบราว์เซอร์ดูเหมือนได้รับการปกป้อง
ip route get 1.1.1.1
curl -4 https://ifconfig.me
sudo ss -tnp | grep -i relayรันสองคำสั่งแรกก่อนและหลังเชื่อมต่อ VPN ของโฮสต์ ถ้าที่อยู่ไม่เปลี่ยน แสดงว่ารีเลย์ไม่ได้อยู่บนอุโมงค์ ไม่ว่าหน้าต่างไคลเอนต์จะพูดอย่างไร อุโมงค์แบบส่วนตัวเท่านั้นยังปล่อยปลายทางสาธารณะไว้ที่ทางออกปกติของโฮสต์ ซึ่งดูเหมือนการรั่วไหล แต่เป็นนโยบายที่คุณตั้งไว้
DNS ถูกแก้ไขบนโฮสต์สำหรับทราฟฟิกที่ผ่านรีเลย์ ตัวแก้ไขชื่อของโฮสต์จึงเป็นตัวกำหนดว่าเซิร์ฟเวอร์ใดเห็นชื่อเหล่านั้น การตั้งค่า DNS แบบส่วนตัวบนโทรศัพท์ไม่ได้ติดไปกับรีเลย์ และการทดสอบตัวแก้ไขชื่อฝั่งโทรศัพท์จะไม่อธิบายการค้นหาของโฮสต์
ตรวจสอบแต่ละช่วงแยกจากกัน
การตรวจสอบสามอย่างตามลำดับนี้ โทรศัพท์ไปถึงรีเลย์ รีเลย์ไปถึงปลายทางภายใต้นโยบายของโฮสต์ และแอปแก้ไขชื่อและใช้ปลายทางนั้นอย่างถูกต้อง หยุดที่ความล้มเหลวแรกแทนที่จะโหลดหน้าใหม่และเดา
adb shell dumpsys connectivity | grep -i -A3 vpn
adb logcat -s GnirehtetRelay:V Gnirehtet:Vรายการเครือข่าย VPN ในดัมป์การเชื่อมต่อ แสดงว่าบริการดักจับทำงานอยู่ ส่วนบันทึกของรีเลย์เองแสดงว่ามีโฟลว์เข้ามาหรือไม่ การไม่มีอยู่ในอย่างใดอย่างหนึ่งแยกปัญหาได้สะอาด คือ ไม่มีการดักจับหมายถึงฝั่งโทรศัพท์ ไม่มีโฟลว์หมายถึงฝั่งโฮสต์
เบราว์เซอร์ที่ทำงานบนโฮสต์พิสูจน์เส้นทางของเบราว์เซอร์บนโฮสต์ ไม่ใช่เส้นทางของกระบวนการรีเลย์ ให้เทียบที่อยู่ที่แต่ละตัวรายงาน และทดสอบทั้งแหล่งข้อมูลส่วนตัวและหน้าสาธารณะ เพราะอุโมงค์แบบส่วนตัวเท่านั้นอาจกำหนดเส้นทางได้อย่างหนึ่งและไม่ได้อีกอย่าง
ถอดประกอบและเลือกพฤติกรรมเมื่อล้มเหลว
การย้อนกลับเป็นส่วนหนึ่งของคู่มือ หยุดและลบรีเลย์ ถอนการติดตั้งไคลเอนต์ดักจับ และเพิกถอนการอนุญาตดีบักของโฮสต์จากตัวเลือกนักพัฒนาบนโทรศัพท์เมื่องานเสร็จ
gnirehtet stop
gnirehtet uninstall
adb kill-serverตัดสินว่าโทรศัพท์ควรทำอะไรเมื่อรีเลย์หายไป หากไม่มีทางเลือกที่ชัดเจน มันอาจกลับไปใช้ข้อมูลมือถือและปล่อยทราฟฟิกที่คุณพยายามกำหนดเส้นทางให้รั่วออกไป จึงต้องตั้งค่าพฤติกรรมการบล็อกการเชื่อมต่อหรือนโยบาย VPN อย่างตั้งใจ และทดสอบการถอดประกอบก่อนจะพึ่งพามัน
บันทึกโฮสต์ที่ได้รับอนุญาต เวอร์ชันรีเลย์ นโยบายอุโมงค์ของโฮสต์ และขั้นตอนการถอดประกอบ บันทึกนั้นเองที่ทำให้การตั้งค่า tethering แบบย้อนกลับครั้งต่อไปทำซ้ำได้ แทนที่จะเป็นอีกบ่ายหนึ่งของการค้นพบใหม่