Sau khi đổi IP máy chủ, quy tắc SNAT vẫn nêu địa chỉ cũ

Máy chủ đã chuyển sang địa chỉ mới, máy khách vẫn kết nối, và không gì trong những gì họ gửi đến được internet. Chính sự tách biệt đó là manh mối: socket lắng nghe và chuyển tiếp cổng đã sống sót qua lần chuyển, nên đường hầm dựng lên, trong khi bản dịch nguồn áp dụng cho các gói tin được chuyển tiếp vẫn nêu một địa chỉ mà host không còn sở hữu. Các phản hồi cho những gói tin bị ghi lại đó đi đến một máy không còn tồn tại.

Kết nối và chuyển tiếp hỏng ở những chỗ khác nhau

Việc thiết lập phụ thuộc vào điểm cuối mà máy khách đã biết: địa chỉ công khai, chuyển tiếp cổng phía trước và bộ lắng nghe bên trong. Lưu lượng được chuyển tiếp phụ thuộc vào quyết định thứ hai được đưa ra sau khi gói tin vào đường hầm, khi host ghi lại nguồn của nó để các phản hồi tìm được đường về.

Việc đổi địa chỉ chỉ phá vỡ quyết định thứ hai, và đó là lý do triệu chứng được đọc là "đã kết nối nhưng không có internet". Điều này cũng giải thích vì sao các kiểm tra thông thường ở phía máy khách trông vẫn khỏe: bắt tay hoàn tất, máy khách nhận được địa chỉ, và thậm chí ping tới địa chỉ đường hầm của máy chủ có thể trả lời. Hàng giờ bị mất ở máy khách vì một lỗi sống ở phía bên kia, nên bảng quy tắc là nơi đầu tiên cần xem.

Đọc quy tắc và các bộ đếm của nó trước khi sửa

Liệt kê các quy tắc dịch cùng bộ đếm và so sánh nguồn đã cấu hình với những địa chỉ mà host thực sự có. Một quy tắc bị ghi lại sang địa chỉ đã chết thường cho thấy lưu lượng ở chiều vào, vì gói tin đến được nó và được dịch, còn chiều về thì không có gì.

sudo iptables -t nat -L POSTROUTING -n -v --line-numbers
ip -4 addr show

Kiểm tra ba trường khi bạn ở đó: nhóm trong khớp nguồn, giao diện ra nếu quy tắc nêu một cái, và ngoại lệ ngăn lưu lượng giữa các đường hầm bị ghi lại. Ngoại lệ đó dễ mất trong lúc sửa, và mất nó khiến lưu lượng giữa các máy ngang hàng trông như đang chạy trong khi phản hồi của nó đi theo một đường lạ.

Nếu bộ đếm đứng ở số không, gói tin không bao giờ đến quy tắc này và địa chỉ không phải vấn đề hiện tại. Tìm một quy tắc cạnh tranh sớm hơn trong chuỗi, điều xảy ra khi ai đó thêm bản thay thế thay vì sửa bản gốc. So sánh số quy tắc với kết quả bạn đã ghi lại một phút trước. Thứ tự là một phần của cấu hình, không phải chi tiết trang trí.

Thay nguồn, hoặc ngừng nêu nó

Khi host có địa chỉ ổn định, hãy thay quy tắc tại chỗ thay vì thêm một quy tắc nữa. Thay theo số quy tắc giữ được thứ tự mà phần còn lại của chuỗi phụ thuộc vào.

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 10.151.0.40

Khi địa chỉ được cấp động, đừng nêu nguồn nào cả và để nhân chọn cái hiện tại từ giao diện ra. Biến thể đó sống sót qua lần chuyển tiếp theo mà không cần sửa, đổi lại việc giấu đi địa chỉ nào đã được dùng.

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -o eth0 -j MASQUERADE

Xác nhận chuyển tiếp IPv4 vẫn được bật qua cấu hình được quản lý, rồi làm quy tắc trở nên bền vững bằng cơ chế của chính bản phân phối. Một thay đổi chỉ làm trong nhân đang chạy sẽ quay lại ở lần khởi động lại tiếp theo, thường vào một cửa sổ bảo trì mà không ai gắn với thay đổi đó.

Hai cách làm sai việc thay thế

Dịch nhóm sang địa chỉ đường hầm của máy chủ thay vì địa chỉ LAN của nó sẽ gửi phản hồi thẳng trở lại đường hầm, nơi chúng được định tuyến tới một máy khách chưa bao giờ yêu cầu. Kết nối kẹt theo cách trông như vòng lặp định tuyến, vì nó đúng là vòng lặp.

Chồng bản dịch thứ hai lên bản cũ là lỗi còn lại. Quy tắc khớp đầu tiên thắng, nên mục cũ tiếp tục xử lý gói tin cho đến khi bị xóa, và bộ đếm của quy tắc mới vẫn ở số không trong khi mọi người đổ lỗi cho việc thay thế. Xóa bản trùng trước khi thêm bất cứ thứ gì mới. Sau đó đọc lại danh sách một lần nữa và xác nhận rằng đúng một bản dịch khớp với nhóm.

Nếu đường hầm cũng mang IPv6, hãy lặp lại toàn bộ phần rà soát trên ngăn xếp còn lại. Tuyến mặc định IPv6 không có bản dịch và không có tiền tố được định tuyến cũng hỏng âm thầm như vậy, và dễ quên vì mọi thứ bên trên trông giống hệt.

Các dịch vụ đi vào cần bản dịch ngược

Một dịch vụ trên máy khách VPN phải truy cập được từ bên ngoài cần bản dịch đích, không phải bản dịch nguồn: cổng công khai được ghi lại sang địa chỉ đường hầm của máy khách trước khi đi vào. Đường chuyển tiếp sau đó cần một quy tắc rõ ràng cho phép lưu lượng đó.

sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 10.9.8.2:8080

Đừng bao giờ dịch cổng mang chính đường hầm, vì việc ghi lại đó cắt đứt kết nối giúp dịch vụ truy cập được. Giữ cổng đường hầm hoàn toàn ngoài các quy tắc đích. Cuối cùng hãy kiểm chứng từ cả hai đầu: bộ đếm trên quy tắc mới, một bản bắt gói ngắn trên thiết bị đường hầm và một yêu cầu tới địa chỉ bên trong đường hầm trước khi thử địa chỉ công khai.