Relay Tor với máy chủ VPN: vì sao chúng không thể thay thế nhau

Bạn có một địa chỉ, cổng trả lời, và một ứng dụng khách chấp nhận nó mà không phàn nàn. Không điều nào trong số đó biến một relay Tor thành điểm cuối VPN, và sai lầm này rất đắt vì hồ sơ được nhập vào sạch sẽ rồi sau đó thất bại ở bước bắt tay. Tôi dùng bốn kiểm tra dưới đây theo thứ tự; mỗi kiểm tra có một điều kiện dừng, và dừng sớm chính là điểm mấu chốt. Nếu kiểm tra đầu tiên thất bại, những kiểm tra còn lại không thể giúp bạn.

Kiểm tra cổng thực sự phục vụ gì

Một cổng mở chỉ chứng minh có một trình lắng nghe, không hơn. ORPort của một relay nói chuyện bằng các ô riêng của Tor sau bắt tay TLS, nên một lần dò TLS thành công hầu như không cho bạn biết gì về việc liệu một giao thức VPN có được chấp nhận ở đó hay không:

nc -vz 203.0.113.20 443
openssl s_client -connect 203.0.113.20:443 -brief < /dev/null

Hãy đọc chứng chỉ chứ không phải sự thật rằng nó tồn tại. Các relay trình bày một chứng chỉ tự ký với tên cố ý không nổi bật, vì lưu lượng relay phải trông giống HTTPS thông thường; còn chứng chỉ của máy chủ VPN mang tên mà hồ sơ của bạn mong đợi. Nếu bên kia không bao giờ trả lời gói đầu tiên của giao thức VPN, thì việc chỉnh sửa hồ sơ nhiều đến đâu cũng không thay đổi kết quả.

Hãy dừng ở đây nếu địa chỉ không hoàn tất bắt tay mà ứng dụng khách của bạn gửi. Đó là câu trả lời của giao thức, không phải vấn đề cấu hình, và đó là lý do phổ biến nhất khiến một hồ sơ đã nhập bị kẹt ở 'connecting' mãi mãi.

Kiểm tra vai trò của relay, không phải quy mô mạng

Các vai trò relay làm những việc khác nhau. Guard là bước nhảy đầu tiên cho ứng dụng khách, relay giữa chuyển tiếp mạch giữa các relay khác, exit là vai trò chạm tới đích, và cầu là một điểm vào không công khai được phân phát qua BridgeDB. Bảng thuật ngữ của Tor giữ các định nghĩa đó riêng biệt, và việc có thể truy cập được là một phần của mọi vai trò trong khi quyền phục vụ ứng dụng khách tùy ý không thuộc về vai trò nào.

Chính sách exit đáng để đọc vì đó là phần duy nhất giống một quy tắc chuyển tiếp, và nó quy định những đích mà exit cho phép đi ra, không phải những ứng dụng khách được phép vào. Một chính sách exit nghiêm ngặt chặn cổng 25 nói lên điều gì đó về kiểm soát lạm dụng hướng ra, không phải về việc bạn có được trỏ ứng dụng khách OpenVPN tới máy đó hay không.

Hãy dừng nếu bạn lý luận từ danh tiếng: vì relay chuyển tiếp lưu lượng, địa chỉ đó phải chấp nhận lưu lượng của bạn, nhưng điều đó không đúng. Tor chọn đường đi qua đồng thuận và giao thức của riêng nó; ứng dụng khách VPN không phải người tham gia và không có mạch nào để gia nhập.

Kiểm tra xem trình nghe SOCKS là cục bộ hay công khai

Ứng dụng khách của Tor mở một giao diện SOCKS cho các ứng dụng trên cùng một máy, mặc định trên loopback. Trình nghe đó là một tiện ích cục bộ, không phải dịch vụ mà một relay cung cấp cho internet, và việc coi nó như một proxy công khai chính là cách người ta rốt cuộc chạy một relay mở mà họ không hề định trước:

ss -ltnp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 https://check.torproject.org

Địa chỉ liên kết là manh mối. Một SocksPort trên 127.0.0.1:9050 đang làm đúng việc của nó; còn cái lắng nghe trên 0.0.0.0 và truy cập được từ bên ngoài là một proxy mở, và các kiểm soát chính sách truy cập của chính Tor tồn tại chính vì sự phơi bày đó là vấn đề chứ không phải tính năng.

Với một ứng dụng cần Tor, hãy trỏ nó tới cổng loopback và để Tor phân giải tên, điều mà dạng socks5h ở trên thực hiện. Đừng thay địa chỉ relay cho cổng đó; relay không cung cấp giao diện mà ứng dụng của bạn yêu cầu.

Kiểm tra rằng hồ sơ VPN khớp với một điểm cuối thật

Hồ sơ VPN là một bó kỳ vọng: OpenVPN cần chứng chỉ máy chủ hoặc CA, chứng chỉ và khóa của ứng dụng khách, và thường là một khóa TLS, trong khi WireGuard cần khóa công khai của bên kia, một điểm cuối và các IP được phép. Không điều nào trong số đó có thể suy ra từ một địa chỉ và một cổng mở, đó là lý do một hồ sơ được dựng như vậy thất bại ở lần trao đổi đầu tiên chứ không phải khi kết nối.

Khi được giao một hồ sơ, hãy xác minh nó với một điểm cuối bạn kiểm soát hoặc một nhà cung cấp bạn có thể nhận diện:

wg show
openvpn --config client.ovpn --verb 4

Trong nhật ký OpenVPN, lỗi thương lượng TLS gọi tên trực tiếp sự không khớp; trong wg show, một bên không có dòng bắt tay chưa bao giờ hoàn tất lần nào. Cả hai đều nhiều thông tin hơn chỉ báo quay của ứng dụng khách, và cả hai đều chỉ vào vật liệu khóa hoặc giao thức chứ không phải Tor.

Kiểm tra xem bạn thực sự cần biện pháp bảo vệ nào

Đây là kiểm tra quyết định kiến trúc. Trình duyệt Tor cho bạn sự cô lập mạch và phòng vệ chống dấu vân tay mà VPN không có; VPN thay đổi địa chỉ mà một đích nhìn thấy và xác thực bạn với nhà cung cấp. Chọn giữa hai thứ này là câu hỏi về mô hình đe dọa, không phải về khả năng tương thích, và trộn chúng với nhau tạo ra một thiết lập trông riêng tư mà không phải vậy.

Chuỗi có thứ tự. Một VPN mang lưu lượng Tor là một cách sắp xếp được hỗ trợ, vì ứng dụng khách của Tor chỉ cần TCP hướng ra. Một ứng dụng khách VPN được tạo đường hầm bên trong Tor không phải là cùng một thứ và không phải là điều ứng dụng khách Tor triển khai, nên đừng lập kế hoạch dựa trên đó.

Trước khi nhập bất cứ điều gì, hãy xác nhận cả bốn điều:

• Cổng hoàn tất bắt tay của giao thức bạn, không chỉ một kết nối TCP.
• Bạn biết vai trò của máy chủ và không coi việc chuyển tiếp là cho phép.
• Trình nghe SOCKS bạn dùng là loopback và của bạn, không phải một cổng công khai trên relay của người khác.
• Khóa hoặc chứng chỉ của hồ sơ thuộc về điểm cuối mà bạn đang kết nối.