Tor sẵn sàng trước VPN: sắp xếp cổng khởi động cho đúng

Theo dõi một tiến trình tor rồi sau đó khởi động VPN là cách phổ biến nhất để dựng sai chồng công nghệ này. Daemon xuất hiện rất lâu trước khi có thể mang một luồng máy khách, và một khoảng chờ cố định chỉ là phỏng đoán khoác áo phụ thuộc. Cổng phải là trạng thái mà thành phần tiếp theo thực sự cần. Đi qua bốn bước dưới đây theo thứ tự, và coi mỗi bước là một điều kiện riêng chứ không phải một độ trễ cần chỉnh.

Bước 1: chọn phương thức vận chuyển bạn thực sự có

Bắt đầu từ giao thức, vì phần còn lại của thiết kế phụ thuộc vào nó. Giao diện SOCKS của Tor không triển khai UDP ASSOCIATE, nên mọi thứ được mang qua đó phải là một luồng TCP. Một hồ sơ OpenVPN dùng UDP sẽ không hoạt động theo đường này, dù trình giám sát được viết thế nào. Chuyển hồ sơ sang TCP và xác nhận đối tác từ xa chấp nhận nó trước khi bạn chạm vào logic khởi động.

Sau đó xác nhận rằng máy khách của bạn có thể tiếp cận một proxy SOCKS hay không. OpenVPN 2.6 ghi nhận tùy chọn socks-proxy cho hồ sơ TCP, và các máy khách khác nhau cung cấp hỗ trợ proxy khác nhau. Một trình khởi chạy lặng lẽ bỏ qua tùy chọn proxy sẽ kết nối trực tiếp và trông như đang hoạt động, điều này còn tệ hơn là thất bại.

Ghi phương thức vận chuyển đã chọn vào runbook, vì mọi kiểm tra sau đó đều phụ thuộc vào nó.

Bước 2: đọc pha bootstrap, không phải danh sách tiến trình

Giao thức điều khiển của Tor trả lời GETINFO status/bootstrap-phase bằng trạng thái bootstrap mới nhất, gồm phần trăm tiến độ và một nhãn tóm tắt. Câu trả lời đó hữu ích chính vì một bộ điều khiển có thể kết nối sau khi daemon đã hoàn tất bootstrap. Một trình giám sát chỉ lắng nghe sự kiện sẽ bỏ lỡ trường hợp Tor đã sẵn sàng trước khi trình giám sát khởi động.

Xác thực kết nối điều khiển cho đúng cách. Cổng điều khiển là một giao diện quản trị, và bất kỳ ai nói chuyện được với nó đều có thể cấu hình lại daemon. Giữ nó trên localhost, giữ xác thực bằng cookie hoặc mật khẩu được bật, và không xóa cả hai chỉ để đơn giản hóa một script khởi động.

Đọc pha một lần khi khởi động, sau đó đăng ký các sự kiện tiến độ cho chế độ xem trực tiếp.

printf 'AUTHENTICATE\r\nGETINFO status/bootstrap-phase\r\nQUIT\r\n' | nc 127.0.0.1 9051
ss -ltn | grep -E '9050|9051'
tor --verify-config -f /etc/tor/torrc

Một câu trả lời với tiến độ 100 và nhãn done nghĩa là daemon đã hoàn tất khởi động của chính nó. Điều đó chưa có nghĩa là đã có một mạch dùng được tới đích của bạn.

Bước 3: chờ một sự kiện mạch máy khách

Giao thức sự kiện của Tor định nghĩa CIRCUIT_ESTABLISHED, báo rằng máy khách có một mạch mà nó có thể dùng. Đó là tín hiệu sẵn sàng mà một cổng vận chuyển muốn, vì nó gần với năng lực bạn cần hơn là một phần trăm. Đăng ký sự kiện và ghi lại chuyển tiếp, để nhật ký cho thấy khi nào vật mang trở nên dùng được chứ không phải khi nào tiến trình xuất hiện.

Coi sự kiện là sự cho phép thử, không phải bảo đảm về một đích cụ thể. Chính sách thoát vẫn có thể từ chối đối tác từ xa, và chính quá trình bắt tay của VPN vẫn có thể thất bại vì những lý do không liên quan gì đến Tor.

Giữ hai điều kiện tách biệt trong mã. Một giá trị boolean duy nhất tên là ready sẽ gộp chúng lại và làm sự cố tiếp theo không thể đọc được.

Bước 4: đặt cổng VPN theo chính quá trình bắt tay của nó

VPN có điều kiện sẵn sàng riêng, và chỉ nó mới chứng minh đường hầm đã lên. Chờ máy khách báo trạng thái đã kết nối với một địa chỉ được cấp, sau đó kiểm tra rằng yêu cầu proxy vẫn còn hiệu lực. Một vòng lặp thử lại bỏ tùy chọn socks-proxy sau một lần thất bại sẽ kết nối trực tiếp và lặng lẽ đánh bại toàn bộ thiết kế.

Hãy quyết định điều gì xảy ra khi đối tác không tiếp cận được trước khi bạn cần biết. Một lần thử lại có giới hạn với thất bại nhìn thấy được dễ vận hành hơn một vòng lặp vô hạn, và nó cho hệ thống giám sát thứ gì đó để cảnh báo. Cùng quyết định đó áp dụng cho vật mang: nếu Tor khởi động lại, VPN phải được tháo ra và đặt cổng lại thay vì để chạy trên một mạch đã chết.

Cuối cùng, giữ chính sách riêng của ứng dụng trong khi VPN đang tắt. Một trình giám sát chờ đúng cách không làm gì để ngăn một tiến trình không liên quan gửi lưu lượng trực tiếp.

Kiểm tra bốn chuyển tiếp mà bạn phải vượt qua

Bốn trường hợp bao trùm thiết kế: khởi động nguội khi Tor lên trước, một trình giám sát gắn vào Tor đã sẵn sàng, một đối tác VPN không khả dụng, và mất vật mang khi đường hầm đang lên. Mỗi trường hợp có một chuyển tiếp dự kiến khác nhau, và mỗi trường hợp tạo ra một dòng nhật ký khác nhau nếu cổng được viết đúng.

Chạy chúng có chủ đích, từng cái một, và đọc các thay đổi trạng thái thay vì danh sách tiến trình.

journalctl -u tor@default -n 30 --no-pager
systemctl status [email protected]
curl -sS --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip

Khi vật mang rơi, VPN nên đi xuống theo nó trong một khoảng thử lại thay vì mắc kẹt với một đường hầm cũ. Khi Tor trở lại, cổng chỉ nên mở lại sau sự kiện mạch, không phải sau khi tiến trình khởi động. Ghi lại điều kiện nào còn thiếu ở mỗi thất bại, và người trực tiếp theo sẽ không phải dựng lại thứ tự từ các dấu thời gian.