Trường Proxy trong hồ sơ VPN của Apple thực sự làm gì
Điền vào một trường proxy không biến VPN thành HTTP. Có hai kết nối liên quan, và trường này chỉ chạm tới một trong số đó.
Điền trường Proxy trong cấu hình VPN của Apple khiến ta cảm giác nó sẽ chuyển hướng đường hầm qua một cổng web. Nhưng không phải vậy. Trường này chọn một trung gian ở tầng ứng dụng cho lưu lượng mà một ứng dụng tương thích quyết định gửi tới đó. Còn kết nối của chính ứng dụng khách VPN với cổng của nó do giao thức, trình lắng nghe và phương thức vận chuyển bạn đã cấu hình quyết định, và đó là những quyết định riêng.
Hai kết nối, hai chủ sở hữu
Bất kỳ thiết lập nào như vậy đều gồm một kết nối từ ứng dụng khách tới cổng và một kết nối từ ứng dụng tới đích. Phần Proxy nói về kết nối thứ hai, dù nó nằm trong cùng hồ sơ với kết nối thứ nhất.
| Connection | What decides its behaviour |
|---|---|
| VPN client to VPN gateway | The supported protocol, the listening port, the transport and the network policy in between |
| Application to a selected proxy | The application's own proxy support, the configured proxy policy, and the route to that next hop |
Tài liệu tham chiếu cài đặt proxy của Apple liệt kê HTTP, HTTPS, SOCKS và cấu hình proxy tự động, tức là mô tả các lựa chọn proxy của ứng dụng. Không mục nào trong số đó nói gói IPsec hay WireGuard đến được cổng bằng cách nào.
Đây là một kiểm tra nhanh để giải quyết vấn đề. Hãy nêu cổng và giao thức mà ứng dụng khách VPN báo trong nhật ký của nó. Nếu dòng đó vẫn ghi UDP 500 hoặc UDP 51820, trường proxy đã không thay đổi gì ở đó.
Khi trường này là công cụ đúng
Có một trường hợp thực tế trong đó proxy đứng trước đường hầm, nhưng đó là tính năng của ứng dụng khách chứ không phải trường trong hồ sơ. Sách hướng dẫn OpenVPN ghi lại --http-proxy cho các kết nối TCP được truyền qua proxy HTTP CONNECT. Muốn dùng nó cần tùy chọn ứng dụng khách tương ứng, một cổng truy cập được theo cách đó, và một proxy cho phép CONNECT tới cổng đang dùng.
Nếu ứng dụng khách của bạn có tùy chọn đó và mạng cho phép CONNECT tới cổng, nó có thể hoạt động. Nếu ứng dụng khách không có, việc điền proxy hệ thống không có tác dụng gì với đường hầm.
Khi nó không thay đổi gì
Hồ sơ IKEv2 hoặc IPsec không trở thành đường hầm HTTP chỉ vì trường proxy đã được điền. WireGuard cũng vậy, định dạng cấu hình của nó không có khái niệm proxy. Đổi cổng của cổng cũng không đổi giao thức của nó. Và một điểm cuối trả lời HTTPS thông thường không tự động là trình lắng nghe VPN.
Cái bẫy tương tự bắt những người sao chép hồ sơ thời PPTP từ các hướng dẫn iPad cũ. Các tùy chọn vẫn còn trong giao diện; dịch vụ phía sau chúng không còn nói giao thức đó nữa.
Quyết định lớp nào cần sửa
Hãy hỏi lớp nào đã hỏng trước khi thay đổi bất cứ điều gì. Nếu ứng dụng khách không thiết lập được phiên, vấn đề là phương thức vận chuyển và trường proxy không liên quan. Nếu đường hầm hoạt động nhưng một ứng dụng không tới được máy chủ của nó, đáng để xem proxy của ứng dụng. Nếu đường hầm hoạt động và mọi ứng dụng đều thất bại, nghi phạm là định tuyến và DNS bên trong đường hầm.
Với trường hợp đầu, hãy hỏi nhà cung cấp xem họ hỗ trợ phương thức vận chuyển hoặc mạng thay thế đã được phê duyệt nào. OpenVPN trên TCP 443 tồn tại vì một số mạng chỉ cho phép điều đó, và nó vẫn đòi hỏi máy chủ phải lắng nghe.
Đừng coi một cổng UDP bị chặn là sự cho phép tự chế. Hãy giữ nguyên các kiểm tra chứng chỉ hoặc danh tính của cổng thay vì tắt chúng để bắt tay khớp.
Xác nhận hai lớp lần lượt
Trước hết hãy xác nhận đường hầm: xem trang trạng thái của ứng dụng khách để thấy phiên đã thiết lập và số byte khác không. Sau đó đọc trực tiếp cài đặt proxy, với scutil --proxy cho cấu hình hiệu lực hoặc networksetup -getwebproxy Wi-Fi cho giá trị đã lưu. Tiếp theo hãy thử một ứng dụng tôn trọng proxy hệ thống và một ứng dụng bỏ qua nó, vì nhiều ứng dụng gốc bỏ qua nó.
Ba kết quả, ba cách sửa khác nhau.
Nếu cả hai lớp đều báo thành công mà ứng dụng vẫn thất bại, hãy xem chia tách đường hầm, DNS và cài đặt mạng riêng của ứng dụng. Đó là lớp thứ ba, và nó cũng không phải trường proxy.