Hai máy khách VPN, hai địa chỉ công khai: khớp SNAT

Hai máy khách VPN có thể đi ra qua hai địa chỉ IPv4 công khai khác nhau, và quy tắc làm được điều đó ngắn hơn nhiều người tưởng. Thứ khiến nó hoạt động không phải cú pháp iptables mà là trạng thái của gói khi đến chuỗi ra: địa chỉ nguồn ở đó vẫn phải phân biệt được các máy khách. Nếu một masquerade trước đó đã gộp cả hai vào một địa chỉ, không quy tắc nào theo từng máy khách có thể khôi phục sự khác biệt. Hãy giải quyết câu hỏi đó trước, rồi viết bản dịch.

Danh tính nào sống sót đến cổng vào

Quy tắc khớp với địa chỉ nguồn của gói, không khớp tên người dùng VPN và không khớp tên mà ứng dụng khách hiển thị. Mọi thứ dịch gói trước đó trên đường đi quyết định quy tắc của bạn còn thấy được gì. Chạy bảng nat theo thứ tự và tìm điểm mà nguồn vẫn riêng theo từng máy khách.

iptables -t nat -S POSTROUTING

Đọc danh sách đó từ trên xuống. Một quy tắc masquerade gần đầu viết lại nguồn cho mọi luồng khớp, và các mục theo từng máy khách đặt sau nó khớp với một địa chỉ không còn tồn tại. Khi hai thiết bị LAN dùng chung một đường hầm và đến như một địa chỉ nội bộ duy nhất, thiết kế phải thay đổi trước tường lửa: giữ dải nguồn của chúng tách biệt hoặc cấp cho mỗi thiết bị địa chỉ nội bộ riêng.

Gắn việc cấp địa chỉ nội bộ với máy khách đã xác thực. Trao địa chỉ đó cho thiết bị khác là trao cả chính sách ra, và dịch nguồn tự nó không phải bằng chứng danh tính.

Dịch không thể bịa ra địa chỉ

Mỗi địa chỉ công khai phải được cấp hoặc định tuyến đến điểm ra này, và các phản hồi phải tìm được đường quay lại. Một quy tắc gửi lưu lượng từ địa chỉ mà không ai định tuyến ngược lại sẽ bị loại ở đầu xa hoặc bị trả lời tới một máy chủ chưa từng yêu cầu. Một phiên bản của nhà cung cấp đám mây thường đã được dịch địa chỉ công khai sang địa chỉ giao diện riêng trước khi gói rời đi, vì vậy nguồn SNAT phải là địa chỉ mà nhà cung cấp chấp nhận, không phải giá trị bảng điều khiển hiển thị. Hãy đọc mô hình địa chỉ của nhà cung cấp và làm theo nó thay vì sao chép giá trị công khai vào mọi gói.

Trên thực tế, điều đó nghĩa là kiểm tra tiền tố đã định tuyến trong bảng điều khiển của nhà cung cấp trước khi chạm vào tường lửa, và dùng địa chỉ giao diện riêng làm nguồn dịch khi ánh xạ là một-một. Các địa chỉ trong ví dụ dưới đây đến từ dải tài liệu, nên thứ đầu tiên cần thay là chính phần văn bản địa chỉ.

Chèn trước masquerade chung

Xác nhận giao diện ra và chuỗi hiện tại trước khi thêm bất cứ thứ gì. Thứ nhất quyết định quy tắc khớp được gói nào, thứ hai cho thấy điều gì đã đứng trước nó.

ip -4 route show default
iptables -t nat -L POSTROUTING -n -v --line-numbers

Lệnh đầu tiên nêu tên giao diện mà một gói đến internet thực sự rời đi. Lệnh thứ hai in chuỗi kèm số dòng. Mục masquerade chung là dòng mà bạn phải ở phía trên.

iptables -t nat -I POSTROUTING 1 -s 10.88.4.20/32 -o ens3 -j SNAT --to-source 198.51.100.77
iptables -t nat -I POSTROUTING 1 -s 10.88.4.21/32 -o ens3 -j SNAT --to-source 198.51.100.78

Hai quy tắc trên mỗi cái khớp một địa chỉ nội bộ, giới hạn khớp trong giao diện ra và đặt nguồn một cách rõ ràng. Chèn thay vì nối thêm: ở vị trí 1 chúng được đánh giá trước dòng masquerade. Thứ tự giữa hai quy tắc không quan trọng vì nguồn của chúng khác nhau. Thay ens3 bằng giá trị mà lệnh route báo, và giữ các trình quản lý tường lửa khác tránh xa cùng các móc, vì hai công cụ cùng ghi một bảng là lý do thường gặp khiến một quy tắc đúng không có tác dụng.

Chứng minh nguồn bằng luồng mới

NAT có trạng thái gắn một bản dịch khi luồng bắt đầu và dùng lại cho các gói sau, nên một phiên mở trước thay đổi vẫn giữ nguồn cũ sau thay đổi. Chỉ một kết nối mới khởi tạo mới chứng minh được quy tắc.

conntrack -L -s 10.88.4.20 -p tcp --dport 443

Đọc hướng phản hồi của mục đó: đích của nó là địa chỉ mà đầu xa nhìn thấy là nguồn. So sánh với địa chỉ công khai bạn dự định, và coi một mục mang địa chỉ cũ là bằng chứng của luồng bắt đầu quá sớm chứ không phải quy tắc hỏng. Yêu cầu máy khách mở kết nối mới, rồi lặp lại truy vấn. Xóa toàn bộ bảng theo dõi để ép buộc bài kiểm tra sẽ làm gián đoạn mọi phiên khác trên cổng vào.

Dịch vẫn không chọn tuyến, không cho luồng qua bộ lọc và không công bố dịch vụ vào. Một tuyến sai và một quy tắc cho phép thiếu vẫn tiếp tục thất bại sau một quy tắc SNAT hoàn hảo. Kiểm tra cả IPv6 và mọi đường ra phụ, rồi ghi các cặp nội bộ-sang-công khai vào tài liệu của tường lửa để thay đổi tiếp theo bắt đầu từ ánh xạ chứ không phải từ văn bản quy tắc.