ทันเนลแยกสำหรับไคลเอนต์ฮอตสปอตไม่ใช่การยกเว้นรายแอป
การยกเว้นแอปออกจาก VPN เปลี่ยนแค่โทรศัพท์เท่านั้น แล็ปท็อปที่เชื่อมต่อต้องมีกฎส่งต่อของตัวเอง จับคู่ที่ต้นทาง ปลายทาง และ NAT
ข้อกำหนดสองข้อที่ฟังดูเท่ากันไม่ใช่เรื่องเดียวกัน: «ยกเว้นแอปนี้ออกจาก VPN» และ «ส่งปลายทางเดียวนี้ไปนอก VPN สำหรับแล็ปท็อปบนฮอตสปอตของฉัน» ข้อแรกเปลี่ยนวิธีที่ซ็อกเก็ตบนโทรศัพท์เลือกเครือข่าย ข้อที่สองต้องเปลี่ยนการตัดสินใจส่งต่อสำหรับแพ็กเก็ตที่มาจากอุปกรณ์อื่นหลังจากโทรศัพท์ยอมรับมันแล้ว การสับสนระหว่างสองสิ่งนี้ทำให้ไคลเอนต์ฮอตสปอตลงเอยด้วยข้อยกเว้นที่ใช้ได้กับเบราว์เซอร์ของโทรศัพท์เองเท่านั้นเสมอ
สองระบบย่อยเป็นเจ้าของสองคำถาม
Android แยกเครือข่ายของแอปกับเทเธอริงออกจากกัน ซ็อกเก็ตของแอปถูกกำหนดให้เครือข่ายโดยสแตกการเชื่อมต่อ และแอป VPN ตัดสินใจว่าซ็อกเก็ตใดของตัวเองจะเข้าทันเนล แพ็กเก็ตที่ส่งต่อจากไคลเอนต์ที่เชื่อมต่อถูกจัดการโดยระบบย่อยเทเธอริง ซึ่งขอเส้นทาง กฎนโยบาย และการแปลที่อินเทอร์เฟซขาลงจาก netd
การยกเว้นรายแอปถูกประเมินเมื่อแอปเปิดซ็อกเก็ต แพ็กเก็ตที่ส่งต่อไม่เคยไปถึงการตรวจสอบนั้น เพราะมันไม่ได้เกิดจากซ็อกเก็ตของแอปบนอุปกรณ์นี้ นั่นคือเหตุผลทั้งหมดที่การตั้งค่าสองอย่างใช้แทนกันไม่ได้ และไม่ใช่บั๊กในทั้งสองอย่าง
การยกเว้นรายแอปเปลี่ยนอะไรจริง ๆ
ตัวสร้าง VpnService สามารถระบุแพ็กเกจที่อยู่นอกทันเนลด้วย addDisallowedApplication หรือระบุแพ็กเกจเดียวที่อนุญาตภายในด้วย addAllowedApplication แอปเหล่านั้นจะเปิดซ็อกเก็ตบนเครือข่ายพื้นฐาน ขณะที่ VPN ยังคงเป็นเจ้าของเส้นทางเริ่มต้นสำหรับทุกอย่างอื่น
ขอบเขตนั้นแม่นยำ: ซ็อกเก็ตของแพ็กเกจเอง บนอุปกรณ์นี้ ตราบใดที่ทันเนลยังทำงานอยู่ มันไม่ได้บอกอะไรเกี่ยวกับทราฟฟิกที่ส่งต่อ ไม่ได้บอกอะไรเกี่ยวกับอุปกรณ์ที่สอง และไม่ได้บอกอะไรเกี่ยวกับแพ็กเก็ตที่ระบบส่งในนามของเทเธอริง
มันไม่ใช่การควบคุมปลายทางเช่นกัน การยกเว้นเบราว์เซอร์จะยกเว้นทุกที่อยู่ที่เบราว์เซอร์นั้นเข้าถึง รวมถึงที่อยู่ที่คุณต้องการเก็บไว้ในทันเนล เมื่อข้อกำหนดระบุ ปลายทางแทนที่จะเป็นแอป ตัวเลือกแอปจึงเป็นเครื่องมือที่ผิดโดยโครงสร้าง
แพ็กเก็ตที่แชร์อยู่นั้นดูอย่างไรจากมุมของโทรศัพท์
แพ็กเก็ตของไคลเอนต์มาถึงอินเทอร์เฟซฮอตสปอตพร้อมที่อยู่ต้นทางส่วนตัวที่โทรศัพท์กำหนด เช่น 192.168.43.20 และปลายทางสาธารณะ การจะส่งต่อ โทรศัพท์ต้องมีเส้นทางไปยังลิงก์ขาขึ้นและกฎการแปล เพื่อให้คำตอบหาเส้นทางกลับได้ เพราะที่อยู่ส่วนตัวของไคลเอนต์ไม่มีความหมายบนเครือข่ายเซลลูลาร์
Android แสดงออกด้วยกฎนโยบายที่เลือกตารางเส้นทาง และ netd สร้างตารางกับกฎที่เกี่ยวข้องใหม่เมื่อเครือข่ายและ VPN เปลี่ยน หมายเลขตาราง ลำดับความสำคัญของกฎ หรือชื่ออินเทอร์เฟซที่คัดลอกจากโพสต์ฟอรัม หรือจากรุ่นเดียวกันในรีลีสเก่า ไม่ได้สร้างความเป็นเจ้าของที่ยั่งยืน การสร้างใหม่นั้นยังเป็นเหตุผลที่กฎที่เขียนด้วยมืออาจทำงานได้หนึ่งชั่วโมงแล้วหยุดหลังการเชื่อมต่อใหม่ครั้งถัดไป
นโยบายแบบใดที่ข้อยกเว้นฮอตสปอตต้องการจริง ๆ
เขียนการตัดสินใจเป็นต้นทาง ปลายทาง และเส้นทางที่ตั้งใจก่อนแตะกฎ รูปแบบน้อยที่สุดสำหรับปลายทางที่อนุมัติหนึ่งรายการมีลักษณะดังนี้:
| Source | Destination | Intended path |
|---|---|---|
| One authorized hotspot client | One approved public service address | Ordinary cellular uplink |
| The same client | All other covered destinations | Shared VPN |
| The phone's own apps | Their existing destinations | Unchanged phone policy |
ทั้งสองทิศทางต้องสมบูรณ์ สาขาตรงต้องมีเส้นทางที่ใช้ได้ผ่านลิงก์ขาขึ้นเซลลูลาร์ที่บังเอิญเป็นปัจจุบัน สาขา VPN ต้องมีเส้นทางของทันเนลพร้อมสิทธิ์ในการส่งต่อ การแปลต้นทางใด ๆ ต้องตรงกับทางออกที่คุณเลือก เพราะ NAT ที่ใช้บนอินเทอร์เฟซทันเนลแสดงที่อยู่ของทันเนลไม่ใช่ที่อยู่เซลลูลาร์ และเส้นทางขากลับก็ไม่สอดคล้องกับเส้นทางขาไป
คำตอบต้องไปถึงไคลเอนต์ขาลงเดียวกันผ่านสถานะที่ติดตามหรือเส้นทางที่ชัดเจน และตัวนับแพ็กเก็ตขาออกไม่ได้พิสูจน์สิ่งใดในนั้น เก็บการขนส่งภายนอกของ VPN เองไว้นอกขอบเขตของข้อยกเว้นด้วย ไม่เช่นนั้นแพ็กเก็ตตัวพาของทันเนลจะสืบทอดนโยบายที่เขียนไว้สำหรับคำขอเว็บของไคลเอนต์
ที่อยู่หนึ่งรายการที่จับได้ไม่ใช่ปลายทาง
ที่อยู่ IPv4 เดียวที่อ่านจากเบราว์เซอร์เป็นภาพเสี้ยววินาที บริการขนาดใหญ่ตอบจาก anycast หรือจากชุดที่อยู่ขอบที่หมุนเวียน หลายบริการเป็นสองสแตก และขั้นตอนการเข้าสู่ระบบอาจแตะโฮสต์การยืนยันตัวตนและเทเลเมทรีที่หน้าเว็บไม่เคยแสดง ข้อยกเว้นที่สร้างรอบที่อยู่ที่คุณบังเอิญเห็นจะพังในครั้งถัดไปที่บริการปรับสมดุลโหลด
ใช้ที่อยู่ที่ผู้ให้บริการจัดทำเอกสารไว้ หรือช่วงที่ผู้ให้บริการเผยแพร่ และคำนึงถึงทั้งสองตระกูลที่อยู่ หากข้อกำหนดไม่สามารถแสดงเป็นชุดที่มั่นคงได้ มันน่าจะเป็นคำถามเชิงนโยบายสำหรับบริการ ไม่ใช่กลเม็ดการกำหนดเส้นทางบนโทรศัพท์
ตรวจสอบจากฝั่งขาลง
การตรวจสอบสามอย่างตามลำดับนี้: บริการที่เลือกจากแล็ปท็อป ปลายทางธรรมดาที่ต้องอยู่ใน VPN และแอปบนโทรศัพท์ที่ต้องไม่ได้รับผลกระทบ จากนั้นทำซ้ำหลังการเชื่อมต่อใหม่และหลังการเปลี่ยนลิงก์ขาขึ้น เพราะนั่นคือเวลาที่ตารางนโยบายถูกสร้างใหม่
หากการใช้งานการแชร์ของโทรศัพท์ไม่สามารถรักษาสัญญานั้นข้ามการเชื่อมต่อใหม่ได้ ให้ย้ายนโยบายแบบเลือกไปยังเราเตอร์ขาลงที่รองรับ แทนที่จะสะสมกฎ root บนเครื่อง เราเตอร์สามารถแสดงการจับคู่ต้นทางและปลายทางด้วยเจ้าของที่มั่นคง และเอกสารของโมดูลเทเธอริงคือแหล่งอ้างอิงที่ถูกต้องสำหรับสิ่งที่โทรศัพท์ทำจริง