Split tunneling แบบอิงแอปกับแบบอิงปลายทาง: เลือกแบบไหน

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

สองกฎทำงานที่ชั้นต่างกัน

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

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

กฎของแอปเหมาะกับไคลเอนต์มือถือและเอเจนต์ที่จัดการ

Android เปิดเผยตัวเลือกโดยตรง: VpnService.Builder.addAllowedApplication() และ addDisallowedApplication() รับชื่อแพ็กเกจและบังคับใช้การตัดสินใจราย UID ตามที่อธิบายในคู่มือนักพัฒนา VPN ของ Android iOS มีสิ่งที่เทียบเท่าผ่านกฎ VPN ต่อแอปที่อิงตัวระบุบันเดิล ซึ่งมักส่งผ่านโปรไฟล์ MDM มากกว่าการพิมพ์ด้วยมือ

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

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

กฎปลายทางเหมาะกับรายการซับเน็ตและการเข้าถึงไซต์

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

OpenVPN ไปถึงจุดเดียวกันผ่านตารางเส้นทางที่ถูกดัน route-nopull หยุดเซิร์ฟเวอร์จากการกำหนดเส้นทาง จากนั้น route 10.20.0.0 255.255.0.0 vpn_gateway ฝั่งไคลเอนต์ครอบคลุมคำนำหน้าของสำนักงานอย่างแม่นยำ IPv6 เป็นคำสั่งแยกในไคลเอนต์แต่ละตัวเหล่านี้ และการลืมมันเป็นวิธีที่พบบ่อยที่สุดในการรั่วรอบ split IPv4 ที่ดูถูกต้อง

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

ที่ที่ทั้งสองรูปแบบพัง: ตัวช่วย บริการที่ใช้ร่วมกัน ตัวแปลงชื่อ

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

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

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

ขั้นตอน: เลือก ใช้ ตรวจสอบ

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

ใช้รูปแบบที่แคบที่สุดที่คุณแสดงออกได้ แล้วตรวจสอบด้วยการถามตารางเส้นทางแทนไอคอนสถานะของไคลเอนต์:

ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40

สองบรรทัดแรกระบุอินเทอร์เฟซที่ปลายทางจริงจะใช้ wg show พิมพ์รายการคำนำหน้าที่กำหนดค่าไว้ บน Windows Find-NetRoute ตอบคำถามเดียวกับที่สแตกจะตอบเมื่อส่งแพ็กเก็ต หากอินเทอร์เฟซคือทันเนล กฎก็ตรงกัน

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