NAT của VPN nằm ở đâu trong before.rules của UFW và cách kiểm tra

Một quy tắc NAT hoạt động khi gõ trong shell lại thất bại khi dán vào before.rules, vì tệp đó không phải là một script. Nó là tài liệu ở định dạng khôi phục với các phần bảng, khai báo chuỗi và dấu COMMIT cho mỗi bảng. Một dòng ở sai vị trí hoặc hủy toàn bộ quá trình khôi phục hoặc âm thầm bỏ các quy tắc mà bạn tưởng là có. Quy trình dưới đây đặt đoạn vào đúng chỗ khung làm việc mong đợi và chứng minh kết quả trước lần tải lại tiếp theo.

Một lệnh shell không phải tệp khôi phục

Một dòng bắt đầu bằng iptables -t nat là chỉ thị cho tệp nhị phân iptables, trong khi tệp mà UFW đọc là mô tả của một bộ quy tắc hoàn chỉnh. Khác biệt không phải hình thức: định dạng khôi phục phải biết nó đang ở bảng nào, những chuỗi nào tồn tại và bảng kết thúc ở đâu. Một lệnh dán vào tài liệu đó hoặc là lỗi cú pháp hoặc, tệ hơn, là một quy tắc gắn nhầm bảng. Khung làm việc tải các tệp này qua công cụ khôi phục chính vì chúng mang tính khai báo chứ không tuần tự.

Tài liệu cũng được tải như một tổng thể, nên một phần bị hỏng có thể chặn phần còn lại của tệp được áp dụng. Vì vậy một lỗi nhỏ trong đoạn NAT kéo theo các quy tắc lọc xuống cùng, và đó là cách một thay đổi tường lửa trở thành sự cố ngừng dịch vụ.

Đặt đoạn vào bên trong phần bảng hiện có

Một đoạn NAT có hình dạng, và hình dạng quan trọng hơn phần văn bản quy tắc bên trong. Tiêu đề bảng mở phần, các khai báo chuỗi thiết lập bộ đếm, các quy tắc tiếp theo, và COMMIT đóng phần.

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT

Nhóm và giao diện ở trên là chỗ giữ chỗ cho giá trị của bạn; cấu trúc là phần đáng sao chép. Nếu tệp đã có phần *nat, hãy thêm quy tắc vào bên trong phần đó thay vì mở phần thứ hai, vì định dạng mong đợi một COMMIT cho mỗi bảng và hai phần cho cùng một bảng là một lần sửa chữa đang chờ xảy ra. Giữ nguyên các định nghĩa chuỗi của bản phân phối, kể cả những định nghĩa nhà cung cấp thêm cho tích hợp riêng của họ. Sổ tay khung UFW ghi lại các tệp before, user và after cùng yêu cầu về một COMMIT khớp.

Nếu tệp hóa ra trống, đừng điền nó từ một hướng dẫn. Hãy xác nhận gói nào sở hữu nó và chính sách đang hoạt động thực sự là gì, vì một tệp lưu trữ trống không chứng minh nhân không giữ quy tắc nào, và một bộ quy tắc đã nạp không chứng minh lần tải lại tiếp theo sẽ có tệp đầy đủ để đọc. Trước tiên hãy khôi phục đường cơ sở được hỗ trợ, rồi áp dụng lại các thay đổi của trang lên đó.

Kiểm tra ứng viên mà không áp dụng

Công cụ khôi phục có thể phân tích và dựng một bộ quy tắc mà không áp dụng nó, và đó là phép thử rẻ nhất hiện có. Chạy nó trên một bản sao được bảo vệ thay vì tệp đang hoạt động, và đọc văn bản lỗi thay vì chỉ trạng thái thoát. Lỗi phân tích nêu một dòng và thường là một bảng, nhiều hơn những gì một lần tải lại thất bại cho bạn biết.

sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"

Việc vượt qua kiểm tra đó chứng minh tài liệu được phân tích và không gì khác. Nó không chứng minh ứng viên vẫn chứa mọi chuỗi mà UFW phụ thuộc, chỉ cho phép các nguồn bạn dự định, hoặc quản trị từ xa vẫn truy cập được. Đó là những đánh giá riêng, và cái cuối cùng xứng đáng có một phiên thứ hai được mở trước khi bắt đầu.

Chọn công cụ phù hợp với backend đã cài và họ địa chỉ. Một máy chạy backend nft qua lớp tương thích cần lệnh tương ứng, và các quy tắc IPv6 sống trong một tệp hoàn toàn khác.

Giữ chuyển tiếp, NAT và chính sách truy cập tách biệt

Dịch nguồn giải quyết một vấn đề địa chỉ và không cấp gì cả. Chuyển tiếp là một quyền riêng do sysctl và bảng lọc kiểm soát, và đó là thứ người ta quên khi đường hầm định tuyến nhưng không truyền lưu lượng. Chính sách truy cập là quyết định thứ ba về nguồn nào được tới dịch vụ nào, và không quy tắc NAT nào diễn đạt nó. Giữ ba thứ tách biệt chính là điều làm cho một sự cố có thể chẩn đoán thay vì một triệu chứng mơ hồ duy nhất.

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD

Hãy đọc ba đầu ra đó cùng lúc chứ không phải từng cái một. Một quy tắc masquerade với chuyển tiếp bị tắt tạo ra một máy khách kết nối được nhưng không tới đâu, điều mà từ phía máy khách trông giống hệt một lỗi định tuyến và đưa người ta tới tệp sai. Bảng lọc cũng là nơi một accept quá rộng ẩn náu, nên hãy kiểm tra chính sách mặc định của nó khi bạn ở đó.

Xác minh một lần tải lại, một lần từ chối và một lần mất VPN

Ba quan sát tạo nên một bài kiểm tra chấp nhận đầy đủ: việc tải lại thành công, một thao tác máy khách được phép hoạt động, và một yêu cầu lẽ ra phải bị từ chối thì thực sự bị từ chối. Cái thứ ba là cái bị bỏ qua, và nó là bằng chứng duy nhất rằng chính sách đang làm được gì đó.

sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

Sau đó hãy kiểm tra sự cố mà bạn đã thiết kế. Hãy đánh sập đường hầm và quan sát máy chủ làm gì, vì một chính sách chỉ hoạt động khi VPN bật là chính sách có phụ thuộc không được nêu ra. Sau đó tải lại thêm một lần nữa để chứng minh rằng chính tệp, chứ không phải một trạng thái chạy còn sót, tạo ra kết quả hoạt động.

NAT của IPv4 không nói gì về IPv6, nên hãy nêu phạm vi dự kiến cho cả hai họ trong cùng ghi chú với quy tắc. Mục tiêu là một chính sách được quản lý nhất quán, và một đoạn tình cờ phân tích được không phải là bằng chứng của điều đó.