Đường hầm đầy đủ WireGuard: AllowedIPs 0.0.0.0/0 là chưa đủ

Đặt 0.0.0.0/0, ::/0 vào AllowedIPs của một peer là bước mà ai cũng nhớ, và nó chỉ quyết định peer được phép mang loại lưu lượng nào. Những tiền tố này không tạo ra tuyến nào, không chuyển tiếp gì ở phía bên kia và để nguyên trình phân giải của mọi ứng dụng đúng chỗ cũ. Bốn việc riêng biệt phải cùng đúng một lúc thì một đường hầm đầy đủ mới thực sự đầy đủ, và nên kiểm theo thứ tự dưới đây, vì một bước kiểm sau không cứu được bước kiểm trước. Mỗi bước kiểm dưới đây là một sự thật đọc được từ máy, không phải một thiết lập mà bạn hy vọng đã được áp dụng.

Tiền tố của peer chọn gì và không chọn gì

AllowedIPs vừa là bộ chọn vừa là sự cho phép. Nó cho phía cục bộ biết những đích nào được gửi tới peer này, và cho phía nhận biết những địa chỉ nguồn nào peer này được phép trình ra. Đó là toàn bộ công việc. Không có gì trong mô tả đó tạo tuyến trên máy chủ, bật chuyển tiếp ở phía xa hay chạm vào việc phân giải tên.

Đó là lý do một cấu hình có thể trông hoàn chỉnh mà lại hành xử như đường hầm chia đôi. Tiền tố nói rằng peer sẽ chấp nhận mọi thứ; bảng tuyến của máy chủ quyết định cái gì thực sự đến đó, và cổng quyết định có gì đi ra. Không quyết định nào trong ba quyết định ấy nằm trong phần của peer.

Định tuyến cho máy khách, không chỉ danh sách peer

Các trình quản lý như wg-quick lập trình bảng tuyến của máy chủ thay bạn, nên hai tệp cấu hình giống nhau lại hành xử khác nhau tùy vào cách giao diện được dựng lên. Một hồ sơ tối thiểu đủ ngắn để đọc một lần:

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

Hai chi tiết gánh công việc. Address trường là một tiền tố máy chủ duy nhất chứ không phải một mạng con mà máy khách tưởng là của mình, và chính trình quản lý biến AllowedIPs mặc định thành một tuyến mặc định thật sự. Dựng cùng tệp đó bằng ip link và wg setconf thì sẽ không có tuyến nào xuất hiện, trông như đường hầm hỏng nhưng thực ra là đường hầm khỏe mạnh đã bỏ qua bước định tuyến. Sổ tay của wg-quick ghi lại việc định tuyến và Table hành vi mà các trình quản lý đó thêm vào.

Đọc kết quả chứ không đọc tệp: ip route get 1.1.1.1 phải nêu tên giao diện đường hầm, và wg show phải báo một lần bắt tay gần đây với bộ đếm truyền tải đang tăng. Bắt tay mà không có tuyến nghĩa là trình quản lý chưa bao giờ chạy, và sửa lại hồ sơ cũng không khắc phục được. Hãy khởi động giao diện đúng như người dùng sẽ làm, nếu không bài kiểm tra đo shell của bạn thay vì đo bản triển khai.

Giữ điểm cuối ở ngoài đường hầm

Đường hầm đầy đủ bắt mọi đích, kể cả đích mà nó phải nói chuyện để tồn tại. Các trình quản lý xử lý việc này bằng cách thêm một tuyến máy chủ cho điểm cuối qua cổng ban đầu, nên một cấu hình đúng gần như luôn chứa một ngoại lệ có chủ đích. Áp dụng một nửa cấu hình bằng trình quản lý và nửa còn lại bằng tay là cách thường khiến ngoại lệ này biến mất.

Nếu điểm cuối là tên máy chủ phân giải ra nhiều địa chỉ, hoặc ra một họ địa chỉ mà bạn không mang, ngoại lệ đó già đi rất tệ và đường hầm có thể hỏng sau một lần kết nối lại trông như bình thường. Ghim điểm cuối vào một địa chỉ bạn kiểm soát, hoặc xác nhận rằng trình quản lý đánh giá lại nó, và đọc lại tuyến máy chủ sau mỗi lần mạng thay đổi.

Cùng cơ chế đó giải thích vì sao đường hầm đầy đủ và cổng chặn lại đánh nhau. Cổng chặn mong chặn lưu lượng mà đường hầm của bạn đang bắt, nên trên mạng khách sạn và sân bay bạn dựng đường hầm sau khi đăng nhập cổng, không bao giờ trước đó.

Chuyển tiếp và đường về trên cổng

Trên cổng, bật chuyển tiếp cho họ địa chỉ bạn mang, cho phép chuỗi forward theo cả hai chiều khi bạn dịch địa chỉ, và xác nhận đường về bằng một lần tra cứu riêng cho nguồn. Không điều nào trong số đó suy ra từ một lần bắt tay thành công, vì bắt tay chỉ chứng minh hai peer trao đổi được UDP. Nó không nói gì về việc gói đã giải mã sẽ ra sao sau đó.

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

Tra cứu chạy trên cổng chứ không trên máy khách, nếu không bạn sẽ đọc một bảng tuyến khác. Nếu nó nêu sai giao diện, hoặc báo không có tuyến, thì không thay đổi nào phía máy khách tạo được lối ra internet. Khi cổng dịch địa chỉ máy khách lúc đi ra, câu trả lời phụ thuộc trạng thái dịch đó, nên quy tắc phải tồn tại cho cả hai chiều của luồng chứ không chỉ chiều đi.

DNS và trạng thái lỗi, kiểm riêng

Bản thân giao thức không cấu hình trình phân giải của bất kỳ ứng dụng nào. wg-quick áp dụng dòng DNS thông qua tích hợp trình phân giải của bản phân phối, các container và trình duyệt có chồng giao thức riêng có thể bỏ qua nó, và vì thế một cái tên có thể hỏng trong khi đường hầm vẫn mang gói hoàn hảo. Hãy kiểm bằng tên máy chủ thay vì địa chỉ, và ghi lại máy chủ nào đã trả lời thay vì mặc định rằng máy chủ trong hồ sơ đã trả lời.

Các họ địa chỉ là một bài kiểm riêng với câu trả lời riêng. Tuyến mặc định v4 không nói gì về việc kết nối v6 của một ứng dụng sẽ làm gì, và một đường hầm âm thầm rò rỉ họ thứ hai còn tệ hơn một đường hầm hỏng ầm ĩ. Hỏi một cái tên qua từng họ, đọc giao diện mà mỗi yêu cầu đã dùng, và kiểm bộ đếm dịch trước và sau, vì một quy tắc không khớp với gì trông giống hệt một quy tắc bị thiếu.

Cuối cùng, hãy kiểm trạng thái bạn muốn khi đường hầm dừng. Một đường hầm đầy đủ nên hỏng theo hướng đóng đối với lưu lượng mà nó tuyên bố: nếu giao diện xuống và các ứng dụng lặng lẽ tiếp tục qua liên kết vật lý, thì thiết kế là một đường hầm chia đôi với thêm vài bước. Hãy viết ra hành vi hỏng dự kiến, kiểm nó một cách có chủ đích, và kết thúc bằng việc ghi lại bốn câu trả lời — trình quản lý nào dựng giao diện, tuyến nào mang tuyến mặc định, ai chuyển tiếp và dịch trên cổng, và trình phân giải nào trả lời.