OpenVPN trên Android không thêm tuyến nếu thiếu địa chỉ tunnel

Hồ sơ OpenVPN của bạn trên Android không thêm được tuyến vì điện thoại chưa có địa chỉ trên giao diện ảo, nên tuyến không có gì để trỏ tới. Tuyến chỉ trả lời gói tin phải đi đâu. Địa chỉ tunnel trả lời điện thoại là ai bên trong tunnel, và ứng dụng phải cung cấp một địa chỉ trước khi giao diện có thể tồn tại. Hãy đi qua bốn bước kiểm tra dưới đây theo thứ tự và dừng ở lỗi đầu tiên, vì sửa tuyến trước khi có địa chỉ chỉ che đi vấn đề thật.

Đọc lỗi theo đúng thứ tự ứng dụng thực hiện

VpnService.Builder của Android tách riêng hai khái niệm: addAddress() đặt địa chỉ lên giao diện mà ứng dụng đang dựng, addRoute() thêm tiền tố đích, và establish() từ chối tạo giao diện cho tới khi có ít nhất một địa chỉ được thêm. Ứng dụng OpenVPN ánh xạ hồ sơ và các tùy chọn máy chủ gửi xuống đúng vào những lời gọi đó, nên một kết nối chưa bao giờ phân tích địa chỉ thì không thể dựng giao diện.

Đó là lý do dòng nhật ký bạn đang đọc có thể nhắc tới tuyến trong khi nguyên nhân nằm ở bước trước đó. Ứng dụng chỉ tới giai đoạn tuyến sau khi giao diện đã tồn tại; không có địa chỉ thì lời gọi tuyến thất bại ngay hoặc không bao giờ chạy. Khi nhật ký nói không thêm được tuyến, hãy bắt đầu từ địa chỉ chứ không phải từ cú pháp tuyến.

Kiểm tra 1: máy chủ có đặt địa chỉ vào phản hồi không?

Với dịch vụ OpenVPN có định tuyến, địa chỉ đến từ bể địa chỉ của máy chủ hoặc từ việc cấp phát cho từng ứng dụng, và topo quyết định hình dạng của nó. Trên máy chủ OpenVPN 2.4 hoặc mới hơn, dịch vụ dùng topo subnet trông như sau:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

Với hình dạng đó máy chủ gửi xuống thứ tương tự ifconfig 10.8.0.6 255.255.255.0. Bản triển khai topology net30 cũ hơn lại gửi địa chỉ đầu bên kia, ví dụ ifconfig 10.8.0.6 10.8.0.5, nên hồ sơ được chuyển giữa hai mô hình có thể trông đúng nhưng mang mặt nạ mạng sai.

Tìm trong nhật ký kết nối của ứng dụng tập tùy chọn được gửi xuống. Nếu không có dòng ifconfig nào, máy chủ chưa bao giờ gửi địa chỉ hoặc ứng dụng đã từ chối tùy chọn đó. Trên máy chủ dùng client-config-dir, tệp được đặt tên theo common name trên chứng chỉ phải tồn tại và chứa phần cấp phát:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

Kiểm tra 2: ứng dụng có giữ địa chỉ đã nhận không?

Bộ lọc quá rộng là nguyên nhân phổ biến thứ hai. pull-filter có từ OpenVPN 2.4 trở đi, và khi nhiều bộ lọc khớp cùng một tùy chọn thì bộ lọc khớp sau cùng thắng, nên một catch-all đặt ở cuối sẽ xóa địa chỉ mà không báo lỗi:

# removes every pushed option, including the address
pull-filter ignore "ifconfig"
pull-filter ignore "route"

Thu hẹp bộ lọc đúng vào tùy chọn bạn thực sự muốn bỏ và để địa chỉ yên:

# keeps the pushed address, drops one unwanted LAN route
pull-filter ignore "route 10.60.0.0"

Lời khuyên tắt hết pull thường đến từ người chỉ muốn bỏ một tuyến duy nhất. route-nopull là công tắc hẹp hơn: nó giữ ifconfig và các tùy chọn được gửi khác trong khi từ chối tuyến được gửi và các tùy chọn kiểu DHCP. Chỉ dùng khi đó thực sự là điều bạn muốn, và trả lời câu hỏi về địa chỉ một cách riêng.

Kiểm tra 3: địa chỉ này có phải do bạn tự nhập không?

Gán địa chỉ thủ công chỉ chính đáng khi nhà vận hành trao giá trị cho bạn. Nếu bạn tự nhập, địa chỉ phải thuộc subnet của ứng dụng VPN, duy nhất trong các phiên đang hoạt động và khớp với topo máy chủ đang chạy. Sao chép địa chỉ của một cầu nối desktop hay một máy trong LAN từ xa đều sai ở cả hai điểm: điện thoại sẽ đòi một địa chỉ đã tồn tại ở nơi khác, và cổng ra không có đường quay lại nó.

Tiền tố LAN từ xa trong một tuyến là đích đến, không bao giờ là danh tính của điện thoại. Tuyến cho 10.60.0.0/24 nói rằng hãy tới mạng đó qua tunnel; nó không nói điện thoại nên giữ địa chỉ 10.60.0.x nào, và điện thoại không nên giữ địa chỉ nào trong số đó. Việc gán tĩnh thuộc về phía máy chủ, nơi chúng không thể xung đột với bể địa chỉ động.

Hai phiên trên cùng một danh tính phơi ra đúng xung đột đó. Nếu cùng một chứng chỉ kết nối hai lần và máy chủ gửi một địa chỉ cố định cho cả hai, phiên thứ hai sẽ trùng với phiên thứ nhất, và cách xử lý là tách danh tính hoặc tách phần cấp phát chứ không phải sửa ở phía ứng dụng.

Kiểm tra 4: có thứ khác đang chiếm chỗ tunnel không?

Android chỉ cho phép một dịch vụ VPN hoạt động tại một thời điểm. Một ứng dụng VPN khác, hoặc mục VPN luôn bật còn để nguyên cho hồ sơ đã hỏng, có thể chiếm chỗ đó trước khi ứng dụng OpenVPN của bạn gọi establish(). Khi đó giao diện không bao giờ xuất hiện dù hồ sơ hợp lệ, nên hãy ngắt VPN kia, tắt thiết lập luôn bật và kết nối lại trước khi động vào hồ sơ.

Dịch vụ khăng khăng dùng cầu nối Ethernet là ngõ cụt còn lại. Ứng dụng Android không root chỉ tạo được tunnel IP, không tạo được đoạn Ethernet đã cầu nối, nên không địa chỉ nào bạn nhập làm máy chủ dev tap chạy được; nhà vận hành phải cung cấp dịch vụ có định tuyến. Khi báo lỗi, hãy kèm tên và phiên bản ứng dụng, tập tùy chọn được gửi xuống, topo và bước chính xác mà địa chỉ lẽ ra phải xuất hiện.

Nếu cả bốn bước kiểm tra đều qua và địa chỉ có mặt, duy nhất và được che đúng, câu hỏi về tuyến trở lại bình thường: máy chủ cho phép những tiền tố nào và ứng dụng nên giới hạn chúng ra sao. Hãy ghi lại địa chỉ tunnel, mặt nạ mạng và topo trước khi đổi bất cứ thứ gì khác, vì ba giá trị đó chính là thứ nhà vận hành cần để đối chiếu với phía máy chủ.