TAP หรือ TUN? ไคลเอนต์ OpenVPN บน Android และเซิร์ฟเวอร์แบบบริดจ์

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

TAP พาเฟรม Ethernet ส่วน TUN พาแพ็กเก็ต IP แอป VPN บน Android ได้รับอินเทอร์เฟซ IP ซึ่งทำให้การจัดวางแบบหนึ่งเป็นไปได้และอีกแบบเป็นไปไม่ได้ ไม่ว่าคอนฟิกจะพูดอย่างไร

การเปรียบเทียบนั้นสั้น แต่เป็นตัวตัดสินว่าคุณแก้ปัญหานี้บนโทรศัพท์ได้หรือต้องเปลี่ยนบริการ

ทันเนลสองชนิดที่มีเพย์โหลดต่างกัน

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

อินเทอร์เฟซ TUN พาแพ็กเก็ต IP ที่ส่งมาถึงมัน ไม่มีชั้นลิงก์ให้เจรจา ไม่มี ARP และไม่มีการออกอากาศ การเราท์ติ้งเป็นตัวกำหนดว่าอะไรเข้าสู่ทันเนล และคอนฟิกฝั่งเซิร์ฟเวอร์ใช้ซับเน็ตแทนบริดจ์

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

สิ่งที่ Android มอบให้แอปจริง ๆ

API VpnService ของแพลตฟอร์มให้อินเทอร์เฟซเสมือนสำหรับแพ็กเก็ต IP แก่แอป ซึ่งกำหนดค่าด้วยที่อยู่ เส้นทาง และ MTU ใน API นั้นไม่มีอแดปเตอร์ Ethernet และแอปก็ไม่มีทางสร้างขึ้นมาเอง

นี่คือเหตุผลที่ OpenVPN Connect ระบุการรองรับการเชื่อมต่อ TUN แบบเราท์บน Android แทนการบริดจ์ TAP คำถามที่พบบ่อยของ Android คือถ้อยแถลงฝั่งไคลเอนต์เกี่ยวกับขอบเขตนี้ และสอดคล้องกับ API ของแพลตฟอร์ม

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

หน้าตาเป็นอย่างไรเมื่อคุณลองอยู่ดี

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

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

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

ฝั่งเซิร์ฟเวอร์ต้องเปลี่ยนอะไร

การแก้ไขเป็นหน้าที่ของผู้ที่ดูแลบริการ VPN และมักเป็นการเพิ่มเติมมากกว่าการย้ายระบบ ให้รันอินสแตนซ์ OpenVPN ตัวที่สองที่มีอุปกรณ์แบบเราท์ ซับเน็ตไคลเอนต์ของตัวเอง และคอนฟิกฝั่งเซิร์ฟเวอร์ที่กำหนดที่อยู่และส่งเส้นทางที่โทรศัพท์ต้องการ อินสแตนซ์แบบบริดจ์เดิมยังคงให้บริการอุปกรณ์ที่ต้องการ Ethernet จริง ๆ

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

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

ตัดสินจากแอปพลิเคชัน ไม่ใช่จากทันเนล

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

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

สุดท้าย เก็บบริการ TAP ไว้สำหรับอุปกรณ์ที่ต้องการ แทนที่จะบังคับให้ทุกไคลเอนต์เลียนแบบอแดปเตอร์ LAN บริการสองอย่างที่มีจุดมุ่งหมายชัดเจนรองรับได้ง่ายกว่าบริการเดียวที่ทำงานได้ครึ่ง ๆ กลาง ๆ สำหรับทุกคน