Nối chuỗi hai VPN: nó che giấu điều gì và tốn những gì

Hai đường hầm lồng nhau không làm bạn ẩn danh. Chúng chia sẻ các quan sát giữa hai nhà cung cấp, vì vậy không bên nào thấy địa chỉ nhà và điểm đến của bạn cùng lúc. Đó là lợi ích thật nhưng hẹp, và nó đi kèm các vấn đề định tuyến, DNS và MTU xuất hiện ngay lần đầu bạn phụ thuộc vào nó.

1. Quyết định xem chặng thứ hai để làm gì

Viết mục tiêu trong một câu trước khi cấu hình bất cứ thứ gì. Nếu mục tiêu là để nhà cung cấp dịch vụ internet của bạn không thấy bạn truy cập trang nào, một đường hầm là đủ. Nếu là để không nhà cung cấp nào một mình có thể liên kết địa chỉ của bạn với lưu lượng của bạn, cần hai. Nếu là để không ai nhận diện được bạn, không số chặng nào đi tới đó.

Chuỗi chỉ mạnh bằng mức ghi nhật ký của nhà cung cấp yếu hơn và hồ sơ tài khoản mà cả hai lưu giữ. Thanh toán, email đăng ký và dữ liệu đo từ xa của ứng dụng nằm hoàn toàn ngoài đường hầm.

2. Làm cho điểm cuối bên trong tiếp cận được qua đường hầm bên ngoài

Sự cố thường gặp là đường hầm bên trong không bao giờ được thiết lập. Kết nối bên ngoài ở chế độ toàn đường hầm sở hữu tuyến mặc định, nên nỗ lực của ứng dụng khách bên trong nhằm tới điểm cuối của chính nó bị đường hầm bên ngoài nuốt mất và bị bỏ hoặc đưa vào vòng lặp. Điểm cuối bên trong cần một tuyến rõ ràng qua giao diện bên ngoài, được cài đặt trước khi ứng dụng khách bên trong khởi động. Nếu không, bắt tay sẽ đua với tuyến và thua.

WireGuard cho thấy cùng xung đột đó từ hướng ngược lại. Ở mỗi peer, AllowedIPs quyết định đích nào đi vào đường hầm đó, nên một giao diện bên trong đòi mọi địa chỉ cũng đòi luôn điểm cuối bên ngoài trừ khi một tuyến cụ thể hơn thắng. AllowedIPs chồng lấn trên hai giao diện là một cấu hình mà một bên thua trong im lặng.

Nối chuỗi bằng container làm rõ sự tách biệt và phơi bày cái bẫy. Một container với không gian tên riêng, tuyến mặc định riêng và một ứng dụng khách bên trong sẽ chuyển tiếp những gì máy chủ gửi tới nó; máy chủ không tự bắt đầu dùng đường đó. Bật chuyển tiếp, thêm tuyến cho đường hầm của container và trỏ dịch vụ tới địa chỉ của container.

3. Giữ DNS trên cùng một đường

DNS phải đi tới nơi lưu lượng đi. Nếu nhà cung cấp bên trong đẩy resolver và máy chủ vẫn hỏi resolver cục bộ, những truy vấn đó tiết lộ đúng những trang mà đường hầm định che. Hãy kiểm tra bằng cách bắt gói trên từng giao diện đường hầm thay vì tin bảng trạng thái của ứng dụng khách. Rò rỉ ở đây vô hình khi duyệt web bình thường và rõ rành rành trong bản bắt gói.

Thiết kế DNS phân tách khiến việc này khó hơn, vì truy vấn cho một tên cục bộ có thể hợp lệ nằm ngoài đường hầm. Hãy viết danh sách ngoại lệ một cách có chủ đích thay vì khám phá nó từ resolver nào tình cờ trả lời.

4. Đặt MTU trước khi người dùng phát hiện thay bạn

MTU là nạn nhân dễ đoán tiếp theo. Hai lần đóng gói trừ đi hai tiêu đề, và một đường hầm bên ngoài đã hạ MTU đường đi sẽ để lại ít chỗ hơn bên trong. Triệu chứng quen thuộc: yêu cầu nhỏ thành công, truyền lớn và bắt tay TLS bị treo.

ip link set dev wg1 mtu 1280 là cách sửa thô, và kẹp MSS trên bộ chuyển tiếp là cách gọn gàng hơn. Thử lại kết nối hoàn toàn không phải cách sửa.

5. Kiểm tra sự cố bạn thực sự sẽ gặp

Cố ý làm hỏng đường hầm bên ngoài và xem điều gì xảy ra. Một chuỗi lặng lẽ quay về đường trực tiếp khi chặng ngoài chết còn tệ hơn không có chuỗi, vì nó rò rỉ đúng lúc bạn tin rằng mình đã được che chắn. Một kill switch dừng toàn bộ lưu lượng là hành vi nên hướng tới. Ghi lại kết quả, vì bạn sẽ không muốn phát hiện lại điều đó giữa một sự cố.

Độ trễ và điểm hỏng thứ hai là những chi phí thường trực. Hai chặng cũng có nghĩa hai hàng đợi hỗ trợ khi có thứ gì đó hỏng vào giờ bất tiện.