Một ứng dụng qua WireGuard: gắn kết không phải định tuyến

Cấu hình trông giống một công tắc cho từng ứng dụng, nên người ta gắn ứng dụng khách vào giao diện WireGuard và mong chỉ ứng dụng khách đó dùng đường hầm. Điều mà việc gắn kết thực sự làm là chọn một địa chỉ nguồn. Sau đó nhân tra cứu tuyến cho đích, tìm thấy tuyến mặc định thông thường và gửi gói ra qua liên kết vật lý với địa chỉ của đường hầm được gắn kèm. Chỉ một tuyến được chọn cho địa chỉ nguồn đó mới hoàn thành ý định.

Cơ chế có hai nửa: một bảng định tuyến mà chỉ lưu lượng của đường hầm nên dùng, và một quy tắc gửi nguồn khớp đến đó.

Gắn kết đặt một địa chỉ nguồn, không hơn

Linux chọn giao diện ra bằng cách tra đích trong bảng định tuyến, sau khi các quy tắc chính sách đã có cơ hội chuyển hướng việc tra cứu đó. Các quy tắc có thể chọn theo địa chỉ nguồn, dấu tường lửa, giao diện vào, UID hoặc thậm chí cổng; mỗi cách là một cách khác để nói lưu lượng này thay vì tất cả. Cấu hình của ứng dụng khách VPN chọn bảng chứa các tuyến của đường hầm; quy tắc chọn lưu lượng nào được phép tham chiếu bảng đó. Chỉ gắn kết thì không cung cấp cả hai.

Đó là lý do sự cố này trông lạ đến vậy. Ứng dụng chắc chắn dùng địa chỉ của đường hầm, đường hầm chắc chắn đang chạy, và lưu lượng chắc chắn đi ra qua giao diện sai. Mỗi câu đều đúng, và cùng nhau chúng mô tả một hệ thống mà không có gì nối địa chỉ với tuyến.

Cho đường hầm bảng riêng của nó

wg-quick cài các tuyến ở nơi cấu hình hồ sơ chỉ định. Thêm Table = 40 dưới [Interface] chuyển chúng sang bảng 40 thay vì bảng chính. Đưa giao diện lên và xác nhận chúng đã đến: ip -4 route ls table 40 phải hiển thị các tuyến của đường hầm, và ip -4 route get 10.66.127.142 cho thấy nhân hiện phân giải một trong số đó thế nào. Khi các tuyến nằm trong bảng riêng, bảng chính vẫn hoạt động cho mọi thứ khác.

Làm điều tương tự cho IPv6 thay vì khớp một tiền tố rộng. ip -6 rule add from fd00::2/128 lookup 40 ghim một địa chỉ; fc00::/8 có thể xung đột với các giao diện khác trên máy chủ và tạo ra một quy tắc khớp nhiều hơn dự định.

Thêm quy tắc nguồn và xem các bộ đếm

Sau đó nối hai nửa: ip -4 rule add from 10.66.127.142/32 lookup 40, với cùng địa chỉ đó gắn vào giao diện WireGuard. Đặt cả hai quy tắc trong PostUp để khi kết nối lại chúng được khôi phục. Kiểm chứng bằng một yêu cầu thật thay vì một cấu hình: ip route get 1.1.1.1 from 10.66.127.142 phải nêu tên thiết bị của đường hầm, và curl --interface wg0 ifconfig.me phải báo địa chỉ của đường hầm chứ không phải địa chỉ ở nhà.

Khi vẫn thất bại, hãy đọc ip -s rule. Một quy tắc tồn tại nhưng chưa bao giờ khớp sẽ hiển thị bộ đếm bằng không, và điều đó phân biệt quy tắc sai với việc không có quy tắc nào. Chỉ một lệnh đó tiết kiệm rất nhiều phỏng đoán về việc ứng dụng có bỏ qua cấu hình giao diện của nó hay không.

Trường hợp ngược lại: giữ SSH ngoài đường hầm

Vấn đề ngược lại cũng phổ biến không kém: wg-quick sở hữu tuyến mặc định và phiên SSH đến máy chủ chết giữa chừng. Các quy tắc của nó nằm ở số ưu tiên thấp, nên một ngoại lệ phải được đánh giá trước chúng. ip rule add dport 22 ipproto tcp table main priority 123 làm điều đó trên một iproute2 gần đây; ở nơi không có bộ chọn, hãy đánh dấu luồng trong nftables và khớp dấu thay thế.

Cũng hãy kiểm tra đường về. Một phiên SSH thiết lập rồi im lặng thường có định tuyến không đối xứng: một chiều đi ra qua đường hầm và chiều kia qua giao diện vật lý. ip route get cho địa chỉ máy chủ cho biết câu trả lời sẽ đi về hướng nào.

Ghi lại số bảng, quy tắc nguồn và ngoại lệ ngay trong cấu hình hồ sơ. Cả ba thuộc về một thiết kế và sẽ được sửa cùng nhau.