TAP hay TUN? Ứng dụng OpenVPN trên Android và máy chủ cầu nối

Một hồ sơ chạy được trên máy tính xách tay lại thất bại trên điện thoại. Bước hiển nhiên là sửa một từ trong cấu hình ứng dụng. Từ đó sẽ không giúp gì, vì hai đầu không nói về cùng một loại lưu lượng.

TAP chở khung Ethernet. TUN chở gói IP. Một ứng dụng VPN Android được cấp một giao diện IP, điều này khiến một trong hai cách bố trí khả thi và cách còn lại thì không, bất kể cấu hình nói gì.

So sánh thì ngắn, nhưng nó quyết định bạn sửa được trên điện thoại hay phải thay đổi dịch vụ.

Hai kiểu đường hầm với tải trọng khác nhau

Giao diện TAP hoạt động như một bộ điều hợp Ethernet. Nó chở khung, nghĩa là ARP, quảng bá và mọi thứ khác mà một LAN chở bên dưới IP. Đó là điều khiến cầu nối khả thi: đường hầm mở rộng một miền quảng bá và các ứng dụng khách hành xử như thể được cắm vào một bộ chuyển mạch.

Giao diện TUN chở các gói IP được gửi tới nó. Không có tầng liên kết để thương lượng, không ARP và không quảng bá. Định tuyến quyết định thứ gì đi vào đường hầm, và cấu hình phía máy chủ dùng một mạng con thay vì cầu nối.

Hai đầu phải thống nhất xem chúng đang làm cách nào. Đổi dev tap thành dev tun ở một phía không chuyển đổi dịch vụ; nó tạo ra một ứng dụng khách mong đợi đường hầm có định tuyến và một máy chủ vẫn gửi khung, và bắt tay có thể thành công trong khi không có gì dùng được đi qua.

Android thực sự trao cho ứng dụng những gì

API VpnService của nền tảng cấp cho ứng dụng một giao diện ảo cho gói IP, được cấu hình với địa chỉ, tuyến và MTU. Trong API đó không có bộ điều hợp Ethernet, và ứng dụng không thể tự tạo ra một cái.

Vì thế OpenVPN Connect ghi nhận hỗ trợ kết nối TUN có định tuyến trên Android thay vì cầu nối TAP. Câu hỏi thường gặp về Android là phát biểu từ phía ứng dụng khách về ranh giới đó, và nó khớp với API của nền tảng.

Công cụ mạng có quyền root, phần sụn tùy chỉnh hoặc sản phẩm triển khai một tầng chuyển đổi rõ ràng là những cách bố trí khác. Trường hợp thông thường là trường hợp nên tính đến: một ứng dụng có thể nhập tệp của bạn và chạy như người dùng bình thường, với một giao diện IP và không có gì bên dưới.

Trông thế nào khi bạn vẫn thử

Kết nối thường được thiết lập. Đó là điều khiến thất bại trở nên khó hiểu: ứng dụng khách báo đã kết nối, nhật ký máy chủ hiện một đối tác, và không ứng dụng nào hoạt động.

Lưu lượng gửi tới địa chỉ được cấp cho điện thoại không đến nơi, vì máy chủ cầu nối khung tới một địa chỉ MAC mà điện thoại chưa từng có. Việc khám phá phụ thuộc quảng bá vẫn trống. Nếu LAN dựa vào DHCP qua cầu nối, điện thoại sẽ không nhận được thuê bao theo cách đó, và địa chỉ gán thủ công trong mạng con đã cầu nối vẫn không tạo ra giao diện còn thiếu.

Một số ứng dụng khách thất bại sớm hơn, khi nhập hồ sơ, lúc gặp loại thiết bị mà chúng không thể triển khai. Cả hai hành vi đều có nghĩa như nhau, và không có hành vi nào được sửa bằng cách thêm tuyến, đổi DNS hoặc mở rộng dải địa chỉ của đường hầm.

Phía máy chủ phải thay đổi gì

Việc sửa thuộc về người vận hành dịch vụ VPN, và thường là bổ sung chứ không phải di trú. Hãy chạy một phiên bản OpenVPN thứ hai với thiết bị có định tuyến, mạng con ứng dụng khách riêng và cấu hình phía máy chủ cấp địa chỉ và đẩy các tuyến mà điện thoại cần. Phiên bản cầu nối hiện có tiếp tục phục vụ các thiết bị thực sự cần Ethernet.

Hai chi tiết khiến điều đó chạy được trong thực tế. LAN cần một tuyến quay về cho mạng con ứng dụng khách mới, trỏ tới máy chủ VPN, nếu không phản hồi sẽ không bao giờ trở lại. Và tường lửa trên máy chủ đường hầm phải chuyển tiếp giữa giao diện đường hầm và LAN, và đó là bước thường bị bỏ sót nhất khi một bài kiểm tra từ chính máy chủ thành công.

Nếu người vận hành không thể thêm dịch vụ, giải pháp thay thế là một thiết bị có thể tham gia cầu nối, nghĩa là một máy tính xách tay hoặc bộ định tuyến hành động thay điện thoại. Đó là một lối vòng với chi phí quản lý riêng, không phải cấu hình Android.

Hãy quyết định từ ứng dụng, không phải từ đường hầm

Hỏi xem điện thoại thực sự phải đến đâu, rồi lập bản đồ điều đó. Chia sẻ tệp hoặc trang intranet truy cập bằng tên hay địa chỉ là một yêu cầu IP, và đường hầm có định tuyến đáp ứng được khi DNS phân giải tên và tuyến tồn tại. Công cụ khám phá duyệt miền quảng bá cục bộ không phải yêu cầu IP, và không lượng định tuyến nào lấp đầy được nó.

Bảng đó cũng là yêu cầu cần gửi. Hãy nêu ứng dụng, địa chỉ hoặc tên mà nó dùng, và liệu nó có phụ thuộc vào khám phá hay không. Người vận hành có thể hành động dựa trên mô tả đó, điều mà không ai làm được với một chiếc điện thoại không chịu kết nối.

Cuối cùng, hãy giữ dịch vụ TAP cho những thiết bị cần đến nó thay vì buộc mọi ứng dụng khách bắt chước một bộ điều hợp LAN. Hai dịch vụ với mục đích rõ ràng dễ hỗ trợ hơn một dịch vụ chỉ chạy nửa vời cho mọi người.