SNAT, DNAT và Masquerade: mỗi quy tắc NAT của VPN làm gì

Đặt bắt gói ở cả hai phía của cổng VPN và một luồng duy nhất có thể hiện ra bốn địa chỉ khác nhau. NAT nguồn viết lại nơi gói tự nhận là xuất phát; NAT đích viết lại nơi nó đi tới. Masquerade không phải hướng thứ ba, nó là một quy tắc NAT nguồn lấy địa chỉ từ giao diện ra thay vì một giá trị cố định. Gọi tên đúng cái bạn thực sự cần trong ba cái đó và phần lớn ticket „VPN hỏng“ sẽ thu về một câu hỏi về đường quay lại.

Mỗi quy tắc viết lại điều gì

NAT nguồn, thường viết là SNAT, đổi địa chỉ nguồn của một luồng khi nó rời bộ định tuyến hoặc cổng. Dịch vụ nhận trả lời về địa chỉ đã được dịch, và hộp thực hiện dịch đảo ngược thay đổi bằng trạng thái nó giữ cho kết nối đó. Trên Linux trạng thái ấy sống trong conntrack, vì vậy conntrack -L in các bộ gốc và bộ trả lời cạnh nhau.

NAT đích, tức DNAT, thay vào đó đổi điểm đến. Một gói gửi đến một địa chỉ công cộng trên UDP 51820 có thể được viết lại sang máy chủ WireGuard nội bộ ở 10.8.0.2:51820. Bộ định tuyến gia đình hay bộ cân bằng tải trên đám mây công bố một bộ lắng nghe VPN theo cách ấy, và điều đó không nói gì về việc đường hầm được phép mang gì về sau.

Masquerade thuộc họ SNAT. Quy tắc không nêu địa chỉ nào; nó dùng địa chỉ mà giao diện ra có tại thời điểm gói rời đi. Linux cho nó một đích riêng, và đây là lựa chọn thông thường trên giao diện WAN nhận địa chỉ qua DHCP hoặc PPPoE.

Bảng ánh xạ nằm ở đâu quyết định sự cố

Ghi lại bộ ngay tại mỗi ranh giới: trước đường hầm, bên trong nó và trên giao diện công cộng. Bản bắt gói bên trong đường hầm khác bên ngoài một cách hợp lý, và ai so sánh hai bản mà không biết việc dịch xảy ra ở đâu sẽ đuổi theo sai máy.

Lưu lượng quay lại phải đi qua thiết bị giữ bảng ánh xạ. Nếu gói trả lời chọn đường khác, một uplink thứ hai, một tuyến theo chính sách, hoặc một nhà cung cấp chưa từng nghe về dải riêng của bạn, việc dịch ngược có trạng thái sẽ không bao giờ xảy ra và máy khách chỉ thấy lưu lượng một chiều. Thêm NAT nguồn hiếm khi sửa được tuyến quay lại bị thiếu; nó có thể giấu triệu chứng trên một luồng trong khi phá chính sách dựa trên địa chỉ ở mọi nơi khác.

Sai lầm phổ biến khác là chờ đường hầm tạo ra khả năng định tuyến. Một máy khách riêng có gói đi ra internet cần một cách ra hợp lệ: tuyến mặc định, cổng chuyển tiếp và thường là dịch nguồn sang một địa chỉ công cộng. Chỉ mã hóa không làm cho một địa chỉ riêng trở nên tới được.

Masquerade hay SNAT tường minh

So sánh hai cách theo điều chúng hứa. Masquerade chọn địa chỉ ra, SNAT tường minh ghim nó lại. Trên một cổng có địa chỉ công cộng ổn định, ghim địa chỉ cho log và danh sách cho phép của đối tác một giá trị dự đoán được. Trên một liên kết WAN động, địa chỉ SNAT bị ghim sẽ sai ngay khi hợp đồng thuê đổi, và Masquerade được tạo ra đúng cho trường hợp ấy.

Phạm vi quan trọng ngang với lựa chọn. Một quy tắc Masquerade khớp mọi gói rời cổng, không giới hạn nguồn hay đích, cũng dịch cả lưu lượng bạn muốn để nguyên, kể cả lưu lượng tới các mạng riêng khác. Hãy giới hạn quy tắc trong dải máy khách, đích dự định và giao diện.

IPsec dựa trên chính sách là nơi điều này cắn mạnh nhất. Hướng dẫn chuyển tiếp của strongSwan đi qua việc bật chuyển tiếp IP và thêm quy tắc SNAT nguồn cho máy khách, cùng tài liệu ấy cũng đề cập việc loại trừ lưu lượng phải giữ địa chỉ gốc. Dịch nguồn trước khi chính sách bảo mật khớp vào nó và đường hầm có thể dựng lên trong khi lưu lượng vẫn rơi, vì gói không còn trông giống bộ chọn đã thương lượng.

Cũng phải quyết định đầu xa sẽ thấy gì. Sau khi dịch, một dịch vụ thấy cổng chứ không thấy từng máy khách. Điều đó đơn giản hóa định tuyến quay lại, đồng thời làm phẳng log và vô hiệu hóa danh sách cho phép theo từng máy khách. Nếu việc giữ địa chỉ máy khách là quan trọng, hãy lên kế hoạch một đường quay lại có định tuyến thay vì giấu chúng để một bài kiểm tra đi qua.

Đọc các quy tắc trên cổng Linux

Một cổng truy cập từ xa có máy khách trong 10.8.0.0/24 và giao diện WAN tên eth0 cần chuyển tiếp được bật và một chính sách lọc cho phép luồng đi qua, rồi mới đến lượt bất kỳ quy tắc NAT nào giúp được. Bản iptables giữ cả hai chiều trong bảng nat:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 51820 \
  -j DNAT --to-destination 10.8.0.2:51820

Dạng nftables dùng đúng hai móc ấy với một giao diện có tên và một chuỗi tường minh:

nft add rule ip nat postrouting ip saddr 10.8.0.0/24 oifname "eth0" masquerade
nft add rule ip nat prerouting iifname "eth0" udp dport 51820 dnat to 10.8.0.2:51820

Cả hai đoạn đều giả định chuỗi lọc đã chấp nhận luồng được chuyển tiếp. NAT không phải quy tắc cho phép, và một gói đã dịch đúng vẫn có thể bị bỏ ở bảng sau. Xác nhận bảng ánh xạ đang sống bằng conntrack -L, xác nhận những gì đã nạp bằng nft list ruleset hoặc iptables-save -t nat, rồi bắt gói trên cả hai giao diện để thấy địa chỉ thật sự đổi.

Những kiểu hỏng trông như quy tắc tồi

Lưu lượng kẹp tóc là kiểu kinh điển. Một máy khách nội bộ đi tới máy chủ nội bộ qua địa chỉ công cộng của máy chủ cần DNAT trên đường vào và dịch nguồn trên đường ra, nếu không máy chủ trả lời thẳng cho máy khách và câu trả lời bị từ chối. Cách sửa là một quy tắc thứ hai, hẹp hơn cho đúng trường hợp nội bộ tới công cộng ấy, chứ không phải một quy tắc Masquerade rộng hơn cho mọi thứ.

Dịch hai lần là kiểu âm thầm. Một máy khách vốn đã ở sau NAT cấp nhà mạng đi tới cổng của bạn với địa chỉ bạn không thể định tuyến ngược lại, nên bạn dịch thêm lần nữa. Nó chạy được, nhưng log giờ mang hai chặng địa chỉ riêng và mọi cuộc điều tra đều cần cả hai bảng ánh xạ. IPsec dựa trên chính sách thêm một vòng xoắn thứ ba: dịch trước khi chính sách khớp và bạn nhận một SA đã dựng mà không có lưu lượng đi qua, thứ được đọc như lỗi tường lửa chứ không phải lỗi NAT.

Rồi đến bài kiểm tra đi qua và lần triển khai thất bại. Chạy tay lệnh NAT chỉ chứng minh cơ chế, không chứng minh cấu hình. Một quy tắc thêm lúc đang chạy sẽ biến mất khi khởi động lại hoặc ở sự kiện giao diện kế tiếp, và một quy tắc Masquerade gắn với giao diện đổi số có thể lặng lẽ đổi địa chỉ mà đầu xa nhìn thấy. Hãy đặt quy tắc vào cấu hình của tường lửa sở hữu nó và kiểm tra lại sau khi kết nối lại.

Danh sách kiểm tra trước khi lưu quy tắc

Trước hết gọi tên hướng: nguồn, đích hay cả hai. Sau đó xác định ai phải giữ trạng thái — cổng, bộ định tuyến phía trên hay đối tác IPsec — và xác nhận đường trả lời quay về qua nó. Giới hạn quy tắc trong dải máy khách, đích và giao diện mà bạn thực sự nhắm tới, và quyết định trước xem đầu xa nên thấy cổng hay địa chỉ gốc của máy khách.

Hãy kiểm tra từ máy khách, không phải từ cổng. Trình duyệt ngay trên cổng có thể bỏ qua hoàn toàn quy tắc dịch cho máy khách, nên một trang chạy được ở đó không chứng minh gì về đường hầm. Gửi một yêu cầu bắt nguồn từ máy khách, theo dõi bộ đếm và bảng conntrack, rồi lặp lại sau khi đường hầm kết nối lại và địa chỉ WAN đổi nếu một trong hai điều đó khả thi ở nơi bạn làm việc.