Tại sao IKEv2 trên Android thất bại trên cổng UDP không chuẩn

Cổng vào trả lời IKEv2 trên UDP 4443 vì một lý do nào đó, hồ sơ có trường tên Server, bạn nhập tên máy chủ và cổng, và điện thoại báo rằng nó không thể tiếp cận máy chủ hoặc không thể phân giải địa chỉ. Không có gì bị chặn. Biểu mẫu gốc của Android mong đợi một máy chủ, và điều tương tự đúng trên Windows. Cổng tùy chỉnh là khả năng của ứng dụng khách trước khi là cài đặt của máy chủ, và chỉ một số ứng dụng khách cho phép bạn thể hiện điều đó. Đi qua ba phần theo thứ tự: ứng dụng khách có thể nói gì, máy chủ đang lắng nghe gì và hai đầu có đóng khung gói tin giống nhau không.

Điện thoại thực sự đã gửi gì

Một chuỗi host:port trong trường dành cho tên sẽ được phân giải như một tên. Bộ phân giải không trả về gì cho vpn.example.net:4443, và lỗi bạn thấy là lỗi phân giải tên hoặc không thể tiếp cận, không phải hết thời gian chờ trên một cổng. Sự khác biệt đó quan trọng, vì thử lại với tên ngắn hơn hoặc mạng khác sẽ không bao giờ sửa được một chuỗi mà biểu mẫu không thể phân tích.

Hồ sơ IKEv2 gốc trên Android, giống như ứng dụng VPN tích hợp của Windows, được ghim vào các cổng IKE tiêu chuẩn. Không cái nào hiển thị trường cổng, và không thao tác sửa hồ sơ nào thêm vào. Nếu trình lắng nghe của nhà cung cấp thực sự ở trên 4443, ứng dụng khách tích hợp là công cụ sai, không phải công cụ bị cấu hình sai.

Dùng ứng dụng khách hiển thị cổng

Ứng dụng khách strongSwan cho Android ghi lại một cổng máy chủ có thể cấu hình trong phần cài đặt hồ sơ nâng cao, vì vậy nó xuất hiện trong gần như mọi công thức hoạt động cho thiết kế này. Hỗ trợ đó thuộc về ứng dụng khách đó: một ứng dụng IKEv2 khác, hoặc một bản fork của nhà cung cấp cùng ứng dụng, có thể không hiển thị cùng trường dù daemon strongSwan bên dưới có hỗ trợ.

Yêu cầu nhà cung cấp cung cấp toàn bộ bộ thông tin cùng lúc: tên cổng vào, cổng UDP, phương thức xác thực và danh tính máy chủ mà ứng dụng khách phải mong đợi. Cổng tùy chỉnh không phải lý do để tắt kiểm tra chứng chỉ hay đổi giao thức. Nhập cổng ở nơi ứng dụng khách đã cài mong đợi, và nếu ứng dụng khách đó không có trường như vậy, câu trả lời là một ứng dụng khách khác đã được phê duyệt, không phải một cách lách đoán mò.

Máy chủ có hai cổng, và cả hai phải khớp nhau

IKE bắt đầu trên UDP 500, và việc đi xuyên NAT thường chuyển IKE cùng ESP đã đóng gói sang UDP 4500. Đây là các cài đặt riêng trong strongSwan, nên máy chủ được chuyển sang một cổng tùy chỉnh phải đổi cả hai thành cùng một giá trị:

plugins {
  socket-default {
    port = 4443
    port_nat_t = 4443
  }
}

Khi một cổng phục vụ cả hai vai trò, daemon phải phân biệt IKE với ESP-trong-UDP trên cùng socket, điều đó được làm bằng dấu bốn byte không phải ESP đứng trước một thông điệp IKE. Vì thế ứng dụng khách không thể thương lượng trên cổng tùy chỉnh rồi lặng lẽ tiếp tục trên 4500, và vì thế câu “chỉ cần đổi cổng” che giấu một yêu cầu về đóng khung.

Chuyển tiếp không phải trình lắng nghe

Chuyển tiếp 4443 tới một trình lắng nghe IKE thông thường là chế độ hỏng trông gần như thành công. Trao đổi đầu tiên đến, máy chủ trả lời, rồi kết nối đứng lại hoặc tái tạo khóa vào hư không, vì phản hồi đi ra từ cổng khác và lưu lượng đã đóng gói về sau không bao giờ khớp với trạng thái mà hai đầu đã tạo. Một quy tắc viết lại cổng đích mà không di chuyển trình lắng nghe tạo ra đúng kết quả nửa mở này.

Đường đi cũng phải cho phép UDP từ đầu đến cuối. Việc TCP 443 đi qua mạng khách sạn hay mạng nhà cung cấp không nói gì về IKEv2 trên một cổng UDP, kể cả khi cùng số. Ở nơi chỉ cho phép TCP 443, một cổng UDP tùy chỉnh không biến IKEv2 thành HTTPS, và câu trả lời đúng có thể là một đường truy cập khác chứ không phải một thử nghiệm cổng nữa.

Tách ba giai đoạn khi kiểm thử

Bắt gói trên máy chủ trong khi ứng dụng khách thử một lần. Một yêu cầu không bao giờ đến là câu hỏi về điểm cuối hoặc tường lửa; một yêu cầu đến mà không có phản hồi là câu hỏi về trình lắng nghe hoặc chính sách; một phản hồi rồi sau đó là im lặng là câu hỏi về đóng khung hoặc danh tính.

tcpdump -ni eth0 -vv udp port 4443

Sau đó đọc thông điệp của ứng dụng khách thay vì vòng xoay của nó. Lỗi đề xuất nghĩa là các thuật toán không khớp, lỗi xác thực nghĩa là danh tính hoặc chứng chỉ không khớp, và việc gửi lại lặp đi lặp lại mà không có phản hồi nghĩa là không có gì trả lời trên cổng đó. Kiểm thử từng giai đoạn một và đổi một trường giữa các lần thử; tài liệu strongSwan về đi xuyên NAT mô tả dấu và hành vi cổng mà bản bắt gói đang cho bạn thấy.