Vì sao cổng captive chặn VPN của bạn và cách đăng nhập lại

Trong mạng mở, điểm truy cập của bạn không đơn giản chuyển gói tin ra internet. Một điểm chính sách ở phía trên kiểm tra xem thiết bị đã được cấp quyền chưa, và cho đến khi được cấp quyền, gần như mọi thứ bị bỏ. Ứng dụng VPN của bạn đọc sự im lặng đó như một máy chủ đã chết. Nó hiếm khi nói ra điều đó: WireGuard lặp lại bắt tay vào khoảng không, OpenVPN báo hết thời gian kết nối, và IKEv2 trả về lỗi 809 về một máy chủ từ xa không phản hồi.

Cổng thực sự kiểm soát điều gì

Cổng captive là hai thứ dính liền nhau: điểm quyết định chính sách và bộ chuyển hướng. Khi thiết bị của bạn kết nối và nhận thuê DHCP, mạng đặt bạn vào trạng thái trước khi được cấp quyền.

Trạng thái đó là một tập hợp các quy tắc tường lửa. Nó thường cho qua DNS và cho phép HTTP hoặc HTTPS tới một danh sách ngắn các máy chủ cổng, và bỏ mọi thứ khác. Danh sách được phép là khu vườn có tường bao, và hầu như không bao giờ bao gồm điểm cuối VPN.

Không lần bỏ nào trong số đó là lịch sự. Các gói tin hướng tới máy chủ VPN bị bỏ thay vì bị từ chối, nên ứng dụng không nhận được ICMP unreachable hay TCP reset, chỉ nhận được sự vắng mặt của câu trả lời. Tùy nhà cung cấp, bộ chuyển hướng có thể trả lời cổng 80 bằng chuyển hướng tới trang đăng nhập trong khi cổng 443 bị bỏ hoặc bị chặn bắt. Các chuyển hướng dễ nhận ra vì chúng mang một phản hồi HTTP thường; việc chặn bắt trên 443 cần một chứng chỉ mà trình duyệt của bạn sẽ từ chối tin.

Bản thân việc cấp quyền thường gắn với địa chỉ MAC của thiết bị, đôi khi với IP thuê được, và nó sống trong một bảng phiên có bộ hẹn giờ. Việc đăng nhập tạo ra một mục. Quy tắc tường lửa cho lưu lượng của bạn đi qua chỉ tồn tại chừng nào mục đó còn, và đó là lý do toàn bộ vấn đề quay lại sau đó mà không có gì thay đổi ở phía bạn.

Vì sao bắt tay VPN chết trước khi bắt đầu

Mỗi giao thức có phương thức vận chuyển riêng, và tường lửa trước khi cấp quyền phá mỗi loại theo cách khác. IKEv2 trên Windows và iOS đi trên UDP 500 và UDP 4500; việc bỏ ở những cổng đó hiện ra như 809, hoặc như một thất bại kiểu phân giải tên trên các ứng dụng báo từng giai đoạn riêng. OpenVPN trên UDP 1194 ở trong trạng thái đang kết nối cho đến khi hết thời gian. OpenVPN trên TCP 443 là trường hợp thú vị, vì cổng có thể hoàn tất bắt tay TCP rồi trả lời bằng trang chuyển hướng của nó, nên bạn thấy lỗi TLS thay vì hết thời gian.

WireGuard cho thấy cơ chế rõ nhất. Nó chỉ là UDP theo thiết kế, không có phương án dự phòng TCP, nên tường lửa bỏ UDP không xác định sẽ loại bỏ hoàn toàn phương thức vận chuyển. Ứng dụng tiếp tục gửi các khởi tạo bắt tay với khoảng lùi tăng dần và báo một bắt tay không bao giờ hoàn tất. Không có gì trong thông điệp đó nhắc tới Wi-Fi, và không có gì trong đó gợi ý bạn nên mở trình duyệt.

Các nền tảng cố nhận ra trạng thái trước VPN của bạn. Windows lấy một URL đã biết để quyết định có hiện thông báo đăng nhập hay không, Android yêu cầu một điểm cuối mà lẽ ra phải trả lời 204 No Content, và thiết bị Apple mở một cửa sổ mạng captive nhỏ. Những phép thử đó hoạt động vì cổng trả lời bằng chuyển hướng thay vì nội dung mong đợi. Cùng hành vi đó giải thích vì sao cổng có thể trông hoàn toàn khỏe mạnh trong khi đường hầm của bạn đã chết: phép thử và đường hầm được đánh giá theo các quy tắc khác nhau.

Hết phiên thực sự đặt lại điều gì

Các địa điểm cho phiên hết hạn vì những lý do không liên quan đến tài khoản VPN của bạn: hết thời gian không hoạt động, độ dài phiên tối đa, thuê DHCP mới hoặc kết nối lại vào một điểm truy cập khác. Khi bộ hẹn giờ kích hoạt, mục trong bảng phiên biến mất và tập quy tắc trước khi cấp quyền quay lại đúng như lúc đăng ký.

Một đường hầm đã thiết lập thường sống đủ lâu để trông khỏe mạnh. Các thông điệp giữ kết nối tiếp tục đi ra, và việc ứng dụng có nhận ra hay không phụ thuộc vào cách nó xử lý lưu lượng không có phản hồi, nên đèn trạng thái có thể vẫn xanh một lúc sau khi đường đi mất. Sau đó đường hầm sụp và mọi lần thử kết nối lại đều thất bại trên đúng những cổng bị chặn đó.

Lúc đó lỗi của ứng dụng cho bạn biết mình đang ở giai đoạn nào, nếu đọc kỹ:

Một chi tiết khiến người ta hiểu lầm: khi phiên gắn với địa chỉ MAC, tải lại trang đăng nhập có thể không giúp được. Bạn phải bỏ kết nối và tham gia lại, để cổng thấy một lần thử cấp quyền mới thay vì lần đã hết hạn.

Đăng nhập trước, rồi mới dựng đường hầm

Thứ tự hiệu quả là: cấp quyền cho thiết bị, chứng minh đường đi, khởi động VPN, chứng minh đường hầm, rồi khôi phục chặn thông thường của bạn. Bước cuối quan trọng vì trạng thái tạm thời bạn cần để tới cổng chính là trạng thái mà công tắc an toàn tồn tại để ngăn.

Ứng dụng máy tính để bàn có tùy chọn chặn ngoài đường hầm phải được tạm dừng để trang cổng tải được, và bạn nên giữ các ứng dụng nhạy cảm đóng trong khoảng ngoài đường hầm đó; đó là khoảng duy nhất lưu lượng cục bộ đi ra mà không được bảo vệ. Một thiết bị được quản lý luôn bật nên dùng quy trình do chủ sở hữu công bố thay vì bạn gỡ chính sách. Nếu cổng hiện cảnh báo chứng chỉ, hãy dừng: chấp nhận nó đưa phiên của bạn qua proxy chặn bắt của địa điểm, và proxy đó có thể đọc mọi thứ bạn gửi. Trên Android, khóa dưới VPN luôn bật chặn lưu lượng trước khi đường hầm dựng lên, và một số bản dựng không thể loại trừ luồng của cổng; nếu bản của bạn không làm được, hãy dùng truy cập thay thế của địa điểm hoặc thiết bị khác thay vì để khóa tắt. Các quy tắc theo yêu cầu của Apple có thể được viết để từ chối đường hầm cho đến khi phép thử thành công, và đó là hành vi bạn muốn trong mạng khách sạn.

Hãy xác minh theo thứ tự bằng những công cụ bạn đã có. Trước đường hầm, chạy phép thử với cả tiêu đề và nội dung đều hiển thị, và xem phương thức vận chuyển VPN của bạn có nhận được câu trả lời nào không:

curl -sS -D - http://captive.apple.com/hotspot-detect.html -o -
sudo tcpdump -ni any 'udp port 500 or udp port 4500 or udp port 1194'

Trước khi cấp quyền, một cổng bình thường đưa ra một trong hai câu trả lời: 302 với Location trỏ tới trang đăng nhập, hoặc 200 với nội dung HTML là trang cổng. Ghi lại bạn nhận được cái nào. Chuyển hướng trước khi đăng nhập không phải thất bại; cổng đang nói cho bạn biết nên đi đâu. Sau khi cổng báo thành công, lặp lại lệnh và chờ 200 có nội dung đúng là từ Success. Chính chuỗi đó làm phép thử có ý nghĩa. Nếu máy chủ trả lời bình thường trước khi bạn từng đăng nhập, mạng này không có cổng chặn bắt. Trong bản ghi, việc bỏ trước khi cấp quyền là các gói đi ra mà không có gì trả về, trong khi một đường đi hoạt động cho thấy câu trả lời cho cùng luồng trong khoảng một giây. Hãy kết nối, rồi lặp lại bản ghi.

Nếu đường hầm vẫn thất bại sau khi cổng nói có

Đăng nhập thành công không giống với phương thức vận chuyển được phép. Nhiều địa điểm cho phép cổng và duyệt web thường nhưng chặn hoàn toàn UDP, khiến WireGuard và OpenVPN trên UDP hỏng và TCP 443 vẫn chạy. Nếu TCP 443 đi qua mà UDP không, đó là chính sách của địa điểm chứ không phải ứng dụng bạn cấu hình sai, nên hãy đổi phương thức vận chuyển hoặc chấp nhận giới hạn và đi tiếp. Nếu kết nối lại vẫn thất bại sau đó, hãy giữ lỗi chính xác; nó nêu tên giai đoạn bạn bị kẹt.

Các thất bại khác sống trên thiết bị. Một phiên vẫn gắn với MAC cũ, một bộ điều hợp Wi-Fi thứ hai có thuê riêng, hoặc một ứng dụng đã lưu ngoại lệ chứng chỉ của cổng đều có thể tiếp tục thất bại sau khi cấp quyền lại sạch sẽ. Bỏ kết nối, cấp quyền lại và thử một lần trước khi chạm vào cài đặt ứng dụng. RFC 8952 đáng đọc nếu bạn muốn kiến trúc đằng sau các thành phần bạn đang quan sát.

Nếu bản thân cổng từ chối cấp quyền, vấn đề nằm ở tài khoản hoặc phân bổ thiết bị và không cài đặt VPN nào sửa được. Đổi quốc gia ra của VPN không đặt lại trạng thái truy cập cục bộ của địa điểm; bảng đó gắn với thiết bị của bạn, không gắn với máy chủ bạn chọn. Hãy hỏi người vận hành địa điểm và cho họ thời gian, vì bảng phiên là thứ họ sẽ xem.

Trước chuyến đi tiếp theo, hãy ghi ba điều: trang cổng như bước số không, bước tạm dừng chặn cho mỗi thiết bị bạn mang theo, và một phương thức vận chuyển dự phòng mà bạn đã thực sự thử. Khi một đường hầm hoạt động mười phút trước lại dừng, hãy coi đó là cấp quyền đã hết hạn và kiểm tra lại cổng trước khi chạm vào hồ sơ VPN.