VPN hay proxy: mỗi loại bao phủ những gì và không bao phủ gì

Cả VPN và proxy chuyển tiếp đều thay đổi địa chỉ mà một trang web nhìn thấy, và đó là nơi hầu hết các so sánh dừng lại. Khác biệt quyết định cấu hình của bạn là phạm vi: proxy chuyển tiếp là một trung gian mà ứng dụng của bạn tự chọn dùng, khác với proxy ngược đứng trước một trang web, trong khi VPN di chuyển mọi thứ mà hệ điều hành định tuyến vào một đường hầm. Mã hóa, xử lý DNS và hành vi khi lỗi đều xuất phát từ sự phân chia đó. Hãy thực hiện năm kiểm tra này theo thứ tự, và cái đầu tiên thất bại sẽ cho bạn biết công cụ nào bạn thực sự cần.

Trung gian bao phủ những ứng dụng nào?

Tiện ích proxy trong trình duyệt chỉ áp dụng cho hồ sơ trình duyệt đó. Ứng dụng email, trình quản lý gói và trình duyệt thứ hai tiếp tục dùng cài đặt riêng của chúng, và một số ứng dụng bỏ qua hoàn toàn các biến proxy của hệ thống. VPN bao phủ những gì bảng định tuyến gửi vào đường hầm, có thể là tất cả ứng dụng hoặc một tập con trong đường hầm chia tách tùy theo tuyến và chính sách máy khách.

Hãy kiểm tra những ứng dụng quan trọng thay vì khái quát từ một lần tải trang. curl https://ifconfig.me tuân theo các biến proxy của môi trường; một ứng dụng máy tính để bàn có thể không. Trên Windows, netsh winhttp show proxy in ra proxy WinHTTP mà các dịch vụ dùng, và đó là cài đặt khác với cài đặt của trình duyệt.

Bước nhảy có được mã hóa không, và TLS kết thúc ở đâu?

Giao thức proxy là điểm hẹn, không phải bảo đảm. SOCKS5 chuyển tiếp TCP mà không mã hóa, và proxy HTTP thường chở dòng yêu cầu cùng các tiêu đề dưới dạng văn bản rõ. HTTPS qua proxy dùng CONNECT, nên phiên TLS của bạn vẫn kết thúc tại đích chứ không phải tại proxy. Hướng dẫn của MDN về máy chủ proxy và đường hầm mô tả sự khác biệt đó từ phía giao thức.

VPN mã hóa đoạn giữa thiết bị của bạn và điểm cuối của nó. Ngoài điểm cuối, các quy tắc giống như trên bất kỳ mạng nào khác, đó là lý do một đường hầm đơn thuần không bảo vệ ứng dụng gửi thông tin đăng nhập qua HTTP thường. Không thiết kế nào trong hai thiết kế che giấu tài khoản đã đăng nhập, cookie hay dấu vân tay trình duyệt.

curl -v -x http://127.0.0.1:3128 https://example.com/ -o /dev/null
curl -v -x socks5h://127.0.0.1:1080 https://example.com/ -o /dev/null

Đầu ra chi tiết cho biết curl đã gửi CONNECT tới cổng 443 hay một GET thường với URL đầy đủ. Với socks5h://, tên máy chủ được giao cho proxy bên trong yêu cầu SOCKS5 rồi proxy chuyển tiếp TLS mà nó không đọc được, nên nó thấy tên và số byte. Qua proxy http://, một URL https:// là CONNECT, nên proxy đó cũng thấy tên và khối lượng của đích, nhưng không thấy yêu cầu hay phần thân phản hồi.

Bộ phân giải nào thấy tên?

Việc phân giải tên có thể diễn ra cục bộ trước khi yêu cầu rời đi, hoặc từ xa tại proxy. Với curl, socks5h:// gửi tên máy chủ tới proxy trong khi socks5:// phân giải nó cục bộ trước. Cài đặt proxy của trình duyệt cung cấp một tùy chọn DNS tương đương, và các tệp PAC có thể định tuyến các máy chủ khác nhau theo cách khác nhau.

Hai giao thức có thể vượt qua proxy mà không cần bất kỳ cấu hình sai nào. WebRTC thu thập ứng viên qua STUN, và QUIC chạy HTTP/3 trên UDP, điều mà proxy TCP không thể chở. Trình duyệt sẽ quay lại TCP nếu UDP 443 bị chặn, vì vậy chặn UDP 443 trên tường lửa của máy chủ (hoặc trên router cho cả mạng), chứ không phải một cờ trong trình duyệt, là cách đáng tin cậy để giữ HTTP/3 trong đường đi của proxy.

Hãy kiểm tra bộ phân giải từ góc nhìn của đích, không phải từ máy tính xách tay của bạn. Một yêu cầu đến với địa chỉ thoát của proxy nhưng tên được phân giải cục bộ vẫn cho bộ phân giải cục bộ biết bạn truy cập những trang nào.

Điều gì xảy ra khi trung gian thất bại?

Một proxy tường minh thất bại theo kiểu đóng: dừng tiến trình proxy và trình duyệt hoặc ứng dụng trả về lỗi kết nối thay vì đi thẳng. Các thiết lập PAC và WPAD là những thứ thất bại theo kiểu mở - nếu không lấy được script, máy khách quay về DIRECT và trang lại thấy địa chỉ thật của bạn. VPN có thể thất bại theo kiểu mở hoặc đóng tùy theo máy khách và việc công tắc ngắt hoặc quy tắc tường lửa có đang hoạt động hay không.

Hãy thử trường hợp lỗi một cách có chủ đích: dừng dịch vụ proxy và tải lại; nếu bạn nhận được trang lỗi thay vì tải trực tiếp, hãy trỏ URL PAC tới một máy chủ không thể truy cập để xem phương án dự phòng. Nếu trang vẫn tải qua tuyến thông thường của bạn, proxy không đưa ra bảo vệ nào trước sự cố của chính nó, và đó là một đặc tính bạn nên biết trước khi dựa vào nó.

Thứ tự quyết định những gì trang thấy. Một proxy có lưu lượng ra đi qua VPN để lại cho trang địa chỉ điểm cuối VPN; đặt proxy bên ngoài đường hầm (VPN tới proxy trên một máy chủ từ xa) và trang sẽ thấy địa chỉ thoát của proxy đó thay vào đó. Dù thế nào, hai bước nhảy có thể ghi lại những thứ khác nhau.

Năm kiểm tra, theo thứ tự

Danh sách kiểm tra dưới đây là toàn bộ quyết định trong một chỗ. Phạm vi đứng đầu vì nó loại bỏ phần lớn sự không khớp: nếu ứng dụng cần được bao phủ không tôn trọng cài đặt thì không có gì phía sau trong danh sách cứu được nó.

Sau đó xác nhận kết quả bằng chính ứng dụng đã tạo ra thay đổi. Tải một trang trong trình duyệt đã cấu hình, lấy cùng trang đó bằng curl, và so sánh địa chỉ mà mỗi bên báo cáo. Nếu chúng khác nhau, vẫn còn một tiện ích, một quy tắc PAC hoặc một ghi đè ở cấp ứng dụng đang hoạt động, và không mức tinh chỉnh đường hầm nào sửa được điều đó.

Hãy ghi lại những gì bạn đã cấu hình: ứng dụng nào dùng proxy, DNS là cục bộ hay từ xa, UDP có bị chặn không, và hành vi khi lỗi là gì. Chính bản kiểm kê nhỏ đó làm cho lần so sánh tiếp theo trở nên khả thi, bởi vì “IP đã thay đổi” chưa bao giờ nói cho bạn biết kiểm tra nào trong năm kiểm tra này đã qua.