VPN bị chặn trên mạng chỉ web? Xử lý theo từng lớp

Một mạng khuôn viên hoặc khách sạn nơi trình duyệt chạy mà mọi đường hầm đều chết không phải một vấn đề, mà là bốn lớp chồng lên nhau. Đường đi có thể chỉ cho phép TCP 443, đòi một proxy có xác thực, kiểm tra bắt tay, hoặc đơn giản là cấm truy cập từ xa bằng chính sách. Xử lý lần lượt giúp bạn không phải mua một ứng dụng mới để sửa một quy tắc mạng. Hướng dẫn dưới đây mất khoảng mười phút và kết thúc bằng một câu trả lời bằng văn bản về lớp nào đã từ chối bạn.

Chứng minh lớp nào từ chối kết nối

Đừng bắt đầu bằng ứng dụng VPN. Hãy bắt đầu bằng một yêu cầu HTTPS đơn giản tới cùng máy chủ và đọc các pha thời gian, vì pha thất bại cho biết thiết bị nào chịu trách nhiệm:

curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n' \
  --max-time 8 https://vpn.example.net/

Không có phản hồi và không có thời gian connect nghĩa là TCP chưa bao giờ hoàn tất, nên có một tường lửa, một yêu cầu proxy hoặc một đích sai trong cuộc. Có thời gian connect mà không có thời gian tls nghĩa là một thứ gì đó ở giữa đã nhận kết nối rồi chặn bắt tay, và đó là dáng vẻ của một proxy kiểm tra nhìn từ phía ứng dụng.

Bây giờ hãy kiểm tra chứng chỉ bạn thực sự nhận được. Đây là cách nhanh nhất để biết bạn đang nói chuyện với máy chủ hay với một hộp trung gian đã ký lại phiên:

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

Đọc dòng nhà phát hành. CA của chính bạn nghĩa là bạn đã tới được dịch vụ; nhà phát hành doanh nghiệp hoặc thiết bị nghĩa là một bộ lọc đã kết thúc kết nối và đang quyết định điều gì tiếp theo. Ghi lại cả hai đầu ra kèm dấu thời gian, vì cùng một bài kiểm tra một giờ sau trên mạng khách có thể cho câu trả lời khác.

Ứng dụng hiểu proxy thay đổi gói đầu tiên, không phải chính sách

Nếu mạng yêu cầu CONNECT qua một proxy có xác thực, phải nói cho ứng dụng VPN biết, nếu không nó sẽ cố mở socket tới một địa chỉ mà nó không thể định tuyến. Hãy thử proxy riêng khỏi ứng dụng, để thất bại chỉ có một lời giải thích:

https_proxy=http://proxy.example.edu:3128 curl -v -o /dev/null https://vpn.example.net/
sudo openvpn --config /etc/openvpn/corp.conf --proto tcp-client \
  --remote vpn.example.net 443 --verb 4

Lệnh đầu tiên chứng minh proxy sẽ mang đích đi. Lệnh thứ hai yêu cầu ứng dụng dùng TCP trên 443, phương tiện duy nhất mà hầu hết các đường chỉ web chuyển tiếp được. Nếu lệnh đầu thành công mà lệnh thứ hai vẫn thất bại, proxy không phải chướng ngại.

Một số ứng dụng đọc proxy của hệ điều hành thay vì phần ghi đè, và một số không đọc cả hai. Hãy xem tài liệu của chính ứng dụng trước khi cho rằng một thiết lập toàn hệ thống có hiệu lực. Một ứng dụng phân giải điểm cuối qua trình phân giải mà proxy không phục vụ cũng sẽ thất bại ở đây, và đó là lý do một thay đổi DNS có thể trông như cách sửa khi nó chỉ là đường vòng.

Cũng để ý kiểu dẫn dụ. Một mạng bị lọc có thể trả lời tên máy chủ phát hiện của nhà cung cấp bằng thứ của riêng nó, điều này thay đổi hồ sơ proxy mà ứng dụng chọn. Đừng xây quy trình quanh sự lạ đó. Nó khác theo từng điểm, thay đổi không báo trước, và không phải thứ bạn có thể hỗ trợ cho người khác.

Cổng 443 là tới được, không phải được phép

Bọc đường hầm trong TLS trên 443 chỉ giải quyết khả năng tới được và không gì khác. Bộ lọc kiểm tra cổng sẽ cho qua; bộ lọc lấy dấu vân tay bắt tay thì không, và lời chào ứng dụng được mã hóa chỉ giấu tên máy chủ khi cả hai đầu hỗ trợ. Hãy chạy bài kiểm tra và biết mình đang ở sau loại bộ lọc nào thay vì hy vọng.

Cũng có một chi phí hiệu năng mà người ta phát hiện sau này. Một phương tiện đáng tin cậy nằm trong một phương tiện đáng tin cậy khuếch đại mất mát, vì ngăn xếp bên trong gửi lại các đoạn mà ngăn xếp bên ngoài đã gửi lại. Trên một liên kết sạch không ai nhận ra. Trên mạng không dây khuôn viên đông đúc, đường hầm trở nên vô dụng đúng lúc bạn cần, và đồ thị trông như mất gói dù không có gì bị bỏ một cách cố ý.

UDP thường là nạn nhân đầu tiên, và điều đó đáng được xác nhận thay vì suy đoán. Nếu WireGuard hoặc OpenVPN mặc định không bao giờ hoàn tất bắt tay trong khi TCP 443 hoạt động, mạng đang bỏ UDP, và không việc tạo lại khóa nào thay đổi điều đó:

sudo wg show
dig +short vpn.example.net
dig +short vpn.example.net @1.1.1.1

Dấu thời gian bắt tay trống bên cạnh một đối tác hôm qua còn chạy là câu trả lời về UDP. Hai truy vấn DNS trả lời một câu hỏi khác: nếu trình phân giải cục bộ và một trình phân giải công cộng không đồng ý về địa chỉ điểm cuối, bạn đang bị dẫn dụ và lập luận về phương tiện là sai.

Xác minh điều gì thực sự rời khỏi máy

Nhật ký ứng dụng mô tả điều ứng dụng tin. Một bản ghi mô tả điều mạng đã thấy, và khác biệt giữa hai thứ đó là nơi phần lớn các trường hợp này được giải quyết:

sudo tcpdump -ni any -c 20 'tcp port 443 and host 203.0.113.10'
sudo ss -tunp | grep -E ':(443|1194|51820)\b'

Nếu bạn thấy gói SYN mà không có SYN-ACK, chỗ chặn ở phía trên và ứng dụng vô can. Nếu bạn thấy một bắt tay hoàn tất tới một địa chỉ không phải của máy chủ, bạn đang nói chuyện với proxy hoặc kẻ chặn. Nếu không thấy gì, hãy kiểm tra rằng bạn đã bắt trên đúng giao diện trước khi kết luận bất cứ điều gì.

Danh sách socket bắt được một trường hợp tinh vi hơn: một đường hầm thứ hai đã giữ tuyến mặc định. Hai ứng dụng tranh nhau bảng định tuyến tạo ra lỗi gián đoạn trông y hệt một mạng bị chặn, và bản ghi sẽ cho thấy lưu lượng rời qua một giao diện bạn không ngờ.

Hoàn tác, và ghi chú đáng giữ lại

Hãy hoàn tác các thay đổi theo thứ tự ngược với thứ tự bạn làm. Bỏ các biến proxy, dừng ứng dụng bạn khởi chạy bằng tay, và gỡ mọi phần ghi đè tuyến hoặc trình phân giải bạn đã thêm:

unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default

Để một ứng dụng khởi chạy bằng tay tiếp tục chạy là cách một laptop kết thúc với mạng hỏng ở lần ghé văn phòng tiếp theo. Các biến proxy để lại trong hồ sơ shell làm hỏng những công cụ không liên quan nhiều tuần sau đó, và người gỡ lỗi chúng sẽ không nối hai sự kiện lại.

Sau đó viết bốn dòng: mạng, dấu thời gian, pha thất bại và nhà phát hành bạn đã thấy. Một đường chạy được ở khuôn viên này và thất bại ở khuôn viên tiếp theo là bình thường, và người tiếp theo cần biết khác biệt là proxy, trình phân giải hay bộ lọc. Nếu câu trả lời là mạng cấm truy cập từ xa, hãy dừng ở đó và hỏi quản trị viên về tuyến được hỗ trợ thay vì mang một đường vòng vào chính sách bạn chưa đọc.