Chuyển tiếp cổng tới một WireGuard peer sau NAT: DNAT cùng SNAT

Trình duyệt yêu cầu https://203.0.113.10:8443, proxy chấp nhận kết nối, và dịch vụ trên WireGuard peer không bao giờ trả lời. Quy tắc DNAT đang làm việc của nó; phần thất bại là phản hồi. Theo dõi gói tin qua cả hai phép dịch và quy tắc còn thiếu trở nên rõ ràng. Cách sửa là thêm một câu lệnh NAT trong hook đúng, không phải đường hầm mới.

Theo dõi một yêu cầu từ đầu đến cuối

Yêu cầu đến giao diện công cộng của proxy, với địa chỉ công cộng của máy khách làm nguồn và địa chỉ của proxy làm đích. Trong nat PREROUTING, quy tắc DNAT ghi lại đích thành địa chỉ đường hầm của peer, 10.90.0.2. Sau đó quyết định định tuyến gửi gói tin ra ngoài qua wg0, và đường chuyển tiếp hoàn tất.

Trên peer, gói tin giờ mang địa chỉ nguồn công cộng gốc, vì không có gì ghi lại nó. Dịch vụ chấp nhận kết nối và gửi phản hồi đến cổng mặc định của chính nó, đó là router gia đình trước peer. Router đó không có trạng thái cho một luồng mà nó chưa từng thấy và hoặc bỏ gói tin hoặc dịch nó sang địa chỉ công cộng của mình, điều mà máy khách sẽ không chấp nhận.

Sự bất đối xứng là toàn bộ vấn đề: yêu cầu đi qua proxy, và phản hồi cố đi trực tiếp. Theo dõi kết nối của proxy chỉ hữu ích nếu phản hồi quay lại qua proxy, và nó không thể quay lại đó khi địa chỉ nguồn vẫn trỏ tới máy khách gốc.

Thêm phép dịch trả về

Viết lại nguồn của luồng được chuyển tiếp sang địa chỉ đường hầm của proxy trước khi nó rời đi tới peer. Sau đó dịch vụ trả lời tới 10.90.0.1, proxy nhận nó, và theo dõi kết nối đảo ngược cả hai phép dịch trước khi gói tin quay về máy khách.

iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

Quy tắc POSTROUTING cố ý hẹp: nó khớp với đích đã dịch và giao diện đường hầm, nên không ghi lại lưu lượng không liên quan tình cờ đi ra qua wg0. Một quy tắc masquerade rộng cũng sẽ che địa chỉ máy khách, nhưng nó sẽ làm vậy cho mọi luồng và khiến bảng NAT khó kiểm toán hơn.

Đặt các quy tắc nơi đường hầm tồn tại

Các quy tắc tham chiếu địa chỉ hoặc giao diện đường hầm phải chạy sau khi wg-quick cấu hình nó. Giao diện được tạo trước PreUp, nhưng địa chỉ, MTU, DNS và tuyến được áp dụng sau đó, và PostUp chạy khi mọi thứ đã vào vị trí. Đặt phần thêm vào PostUp và phần xóa vào PreDown.

PostUp = iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PostUp = iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1
PreDown = iptables -t nat -D PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PreDown = iptables -t nat -D POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

Các lần xóa phải khớp với các lần thêm theo từng token, bao gồm cả khớp multiport và giao diện. Một lần xóa khác đi một khớp sẽ không xóa gì, và lần kết nối lại tiếp theo thêm bản sao thứ hai của quy tắc. Sau vài lần kết nối lại, bảng chứa các bản trùng khó quy cho một dòng cấu hình.

Kiểm tra kết quả với iptables -t nat -S sau khi kết nối lại. Nếu cùng một quy tắc xuất hiện hai lần, dòng PreDown không khớp và việc dọn dẹp âm thầm thất bại.

Chuyển tiếp, lọc và NAT còn lại

Bật chuyển tiếp IPv4 vĩnh viễn, sau đó cho phép luồng được chuyển tiếp trong bảng lọc. DNAT xảy ra trước chuỗi FORWARD, nên quy tắc lọc khớp với đích đã dịch chứ không phải địa chỉ công cộng. Nếu UFW quản lý tường lửa, hãy diễn đạt quyền cho phép như một quy tắc tuyến; quy tắc host đơn giản không bao phủ lưu lượng được chuyển tiếp.

Hai lớp NAT khác vẫn có thể phá vỡ đường đi ngay cả khi quy tắc proxy đúng. Trên kết nối gia đình, địa chỉ công cộng thuộc về router, và mở cổng trong tường lửa của nó không giống với việc tạo một mục chuyển tiếp cổng gửi cổng đó tới proxy. Một cổng trông như mở từ bên ngoài trong khi không có gì trả lời thường thiếu đúng ánh xạ đó.

Trên VPS có NAT, nhà cung cấp ánh xạ một cổng công cộng tới địa chỉ riêng. Ánh xạ phải khớp với cổng bạn quảng bá, và sự không khớp trông giống hệt một đường hầm hỏng. Xác nhận ánh xạ của nhà cung cấp trước khi thay đổi cấu hình WireGuard.

Kiểm tra đường về và chấp nhận chi phí

Kết nối từ một mạng không phải LAN của proxy, sau đó kiểm tra cặp phép dịch khi kết nối đang mở:

conntrack -L -p tcp --dport 8080
tcpdump -ni any tcp port 8080

Mục conntrack phải hiển thị tuple gốc, tuple đã dịch và hướng của phản hồi. Nếu thiếu phản hồi, peer không gửi qua đường hầm, điều này thường có nghĩa là quy tắc SNAT chưa được áp dụng hoặc tường lửa của chính peer đã bỏ luồng.

Khởi động lại một lần để chứng minh PostUp áp dụng lại các quy tắc, sau đó dừng đường hầm và xác nhận PreDown đã xóa chúng. Các quy tắc chết còn sót sau khi ngắt kết nối là lý do một thay đổi sau đó hành xử không thể đoán trước.

Cuối cùng, hãy chấp nhận cái giá của SNAT. Dịch vụ thấy mọi yêu cầu như đến từ proxy, nên nhật ký truy cập, giới hạn tốc độ theo máy khách và danh sách địa chỉ được phép không còn phân biệt người dùng. Trường hợp hairpin cần phép dịch nguồn riêng cho máy khách trên LAN của proxy. Nếu peer cần địa chỉ máy khách thật, giải pháp thay thế là tuyến quay về mạng của máy khách, tốn nhiều công hơn nhưng giữ lại thông tin.