WireGuard trong không gian tên mạng: vì sao socket bị bỏ lại

Giao diện có trong không gian tên bạn muốn, ứng dụng được gắn vào nó, vậy mà lưu lượng đường hầm không bao giờ xuất hiện. Đây là dấu hiệu của một thiết bị WireGuard trong nhân Linux được tạo ở một không gian tên và chuyển sang không gian khác: giao diện đã chuyển đi còn socket UDP được mã hóa thì không. Cả hai phải ở đúng chỗ trước khi lưu lượng bên trong có ý nghĩa. Việc kiểm tra diễn ra nhanh khi bạn biết phải xem hai ngữ cảnh thay vì một.

Triệu chứng: đúng không gian tên nhưng không có gói tin

Bên trong không gian tên, đường hầm trông khỏe mạnh. Thiết bị tồn tại, địa chỉ được gán và cấu hình peer có mặt. Bên ngoài, trao đổi UDP mong đợi không bao giờ xuất hiện trên giao diện bạn đang theo dõi, và phía đối diện báo rằng không có bắt tay.

Lý do là các gói tin bên trong của ứng dụng đến thiết bị đã chuyển, và thiết bị cố gửi chúng qua một socket thuộc ngữ cảnh mạng khác. Tuyến cơ sở mà nó dùng, cùng mọi quy tắc tường lửa áp dụng cho nó, là những gì thuộc không gian tên nơi thiết bị được tạo.

Đây không phải lỗi khi chuyển cũng không phải cấu hình peer sai. Cách hiện thực của nhân hoạt động như vậy, và tài liệu về không gian tên cho WireGuard mô tả trực tiếp quy tắc tạo.

Vì sao socket có nơi sinh

Một thiết bị WireGuard sở hữu một socket UDP cho vận chuyển được mã hóa của nó, và socket đó được mở trong không gian tên nơi thiết bị được tạo. Di chuyển giao diện bằng lệnh liên kết sẽ chuyển thiết bị nhìn thấy được nhưng để vận chuyển ở nơi nó bắt đầu. Khi đó hai đối tượng có chủ sở hữu khác nhau.

Hệ quả dễ bị bỏ qua vì hai nửa được kiểm tra ở hai nơi khác nhau. Tuyến bên trong được quyết định trong không gian tên nơi ứng dụng chạy, còn tuyến bên ngoài được quyết định nơi socket sống. Chỉ kiểm tra một trong hai sẽ cho kết luận tự tin nhưng sai. Kiểm tra cả hai thường kết thúc điều tra chỉ trong một lượt.

Hãy tạo nó ở nơi bạn muốn có socket

Giải pháp là tạo thiết bị bên trong không gian tên đích thay vì tạo bên ngoài rồi chuyển. Giả sử không gian tên đã được phê duyệt đã tồn tại và tên chưa được dùng:

ip netns exec vpn-apps ip link add wg-demo type wireguard
ip netns exec vpn-apps wg show

Giờ cả giao diện và socket của nó thuộc ngữ cảnh đó, nên tuyến cơ sở và các quy tắc lọc áp dụng là những gì được cấu hình ở đó. Nếu thiết kế cần phía rõ ràng ở nơi khác, hãy đặt giao diện cơ sở vào không gian tên trước rồi mới tạo đường hầm. Thứ tự là một phần của thiết kế, không phải chi tiết hiện thực.

Hãy coi chúng là lệnh quản trị mạng, không phải công thức. Chúng tạo thiết bị và hiển thị trạng thái; khóa, peer, địa chỉ và tuyến vẫn phải đến từ cấu hình đã được phê duyệt, và không bao giờ được thay thế một giao diện đang vận hành bằng ví dụ.

Hãy đọc cả hai phía của đường đi

Khi thiết bị đã ở đúng chỗ, xác minh hai quyết định riêng rẽ. Bắt đầu bằng tra cứu bên trong từ ngữ cảnh của ứng dụng, sau đó kiểm tra đường đi bên ngoài từ ngữ cảnh sở hữu socket:

ip netns exec vpn-apps ip route get 10.30.0.9
ip netns exec vpn-apps wg show
tcpdump -ni any udp port 51820

Nếu tra cứu bên trong được giải qua đường hầm và bản ghi bên ngoài cho thấy trao đổi được mã hóa, hai nửa khớp nhau. Nếu bản ghi trống, socket vẫn ở nơi khác, hoặc tuyến cơ sở trong không gian tên của nó không đến được điểm cuối.

Một kiểm tra nữa thuộc về bản ghi: thiết bị được tạo thế nào sau khi khởi động lại. Trình quản lý tạo lại giao diện với ngữ cảnh tạo khác sẽ thay đổi nơi sinh của socket. Một lần chuyển bằng tay thành công không phải bằng chứng về con đường được quản lý.