Đã cài gói tường lửa, quy tắc biến mất sau khi khởi động lại

Gói được cài sạch sẽ, các quy tắc đã được kiểm tra, và sau lần khởi động lại tiếp theo thì cổng kết nối mở toang. Không có gì trong giao dịch thất bại; thứ thất bại là giả định về những gì sẽ tồn tại. Cài công cụ tường lửa, quyết định quy tắc nào nên sống sót và khôi phục chúng đúng thời điểm là ba việc tách biệt.

Triệu chứng thực sự cho bạn biết điều gì

Một bộ quy tắc biến mất khi khởi động lại có một trong ba chủ nhân: không ai lưu nó, thứ khác đã thay thế nó, hoặc nó được khôi phục trước khi thứ nó phụ thuộc vào tồn tại. Hai trường hợp đầu hiện ra trong cấu hình; trường hợp thứ ba chỉ lộ ra ở thứ tự. Đó là lý do một lần khởi động lại có thể trông như mất dữ liệu khi thực chất là vấn đề trình tự.

Hãy bắt đầu bằng việc ghi lại điều gì đúng trước khi khởi động lại: dịch vụ nào giữ các quy tắc, nó đọc tệp hay cơ sở dữ liệu nào khi khởi động, và nguồn đó đã từng được ghi chưa. Một bộ quy tắc đang chạy mà không ai lưu là lời giải thích hợp lý và cũng là trường hợp phổ biến nhất.

Đừng bắt đầu bằng việc cài lại gói.

Hãy đọc công cụ duy trì trước khi dùng

Các công cụ của Debian coi việc duy trì như một vấn đề plugin: mỗi plugin biết cách ghi các quy tắc của riêng nó, và một lớp bọc gọi chúng. Hành động lưu của nó ghi lại mọi thứ đang được nạp tại thời điểm đó, và hành động khởi động nạp lại ảnh chụp đó. Không hành động nào xem xét thứ nó đang lưu.

Đó là một ảnh chụp, không phải một lần rà soát. Một quyền cho phép còn sót lại từ phiên gỡ lỗi, một thử nghiệm dở dang, hay một quy tắc dễ dãi do một trợ thủ khác chèn vào, tất cả đều trở thành vĩnh viễn bên cạnh chính sách bạn định giữ. Lưu trạng thái và phê duyệt trạng thái là hai hoạt động khác nhau, và chỉ một trong hai cần sự phán đoán. Hãy đọc bộ đang nạp trước, rồi quyết định dòng nào xứng đáng sống sót.

Hãy lưu một cách có chủ đích, sau khi đọc thứ đang được nạp.

Quyết định thứ gì nên sống sót

Một số quy tắc thuộc vòng đời của một giao diện và nên biến mất cùng nó. Những quy tắc khác phải sống lâu hơn đường hầm, và ví dụ rõ nhất là một hạn chế cấm lưu lượng của máy khách quay lại giao diện vật lý khi đường hầm sụp. Hai loại đó cần những tác nhân khôi phục khác nhau, không phải một ảnh chụp dùng chung.

Hãy viết kết quả mong muốn cho ba thời điểm: khởi động, kích hoạt VPN và mất đường hầm. Sau đó kiểm tra xem công cụ bạn chọn có diễn đạt được từng thời điểm hay không. Một gói duy trì nạp lại ảnh chụp tĩnh xử lý được thời điểm đầu và có thể không xử lý được thời điểm nào khác, vì ảnh chụp không biết trạng thái đường hầm đổi khi nào. Nếu nó không diễn đạt được, khoảng trống thuộc về một thành phần khác.

Chính sách, không phải gói, quyết định câu trả lời.

Kiểm tra thứ tự khôi phục

Khôi phục tệp không giống như làm chủ kết quả. Một trình quản lý khác có thể thay thế các quy tắc, một accept trước đó có thể che chúng, hoặc máy khách có thể bắt đầu gửi trước khi hạn chế có hiệu lực. Hãy xem xét hành vi lúc khởi động và lúc kết nối lại, không chỉ sự tồn tại của một tệp đã lưu.

systemctl status netfilter-persistent
iptables -S

Đừng cho rằng dừng dịch vụ duy trì là vô hại, vì gói có ghi chép việc xả có điều kiện khi nó dừng. Hãy xác định cấu hình thực tế của dịch vụ trước khi dùng stop hoặc restart như một thử nghiệm trên cổng mà bạn quản trị từ xa. Một phiên console và một bản khôi phục được ghi chép là mức tối thiểu trước thử nghiệm đó.

Thứ tự là thuộc tính của hệ thống đang chạy, không phải của tệp trên đĩa.

Chấp nhận ba kết quả riêng biệt

Ghi lại việc cài gói, bộ quy tắc đã nạp và chính sách được áp dụng như ba sự kiện riêng. Tên gói trong một chủ đề hỗ trợ chỉ trả lời cho sự kiện đầu, và đó là thứ hiếm khi quan trọng.

nft list ruleset

Sau đó kiểm tra một thao tác được phép và một lần từ chối bắt buộc.

Nếu lần từ chối vẫn đứng sau khi khởi động lại và sau khi đường hầm sụp, chính sách đã sống sót. Nếu nó chỉ đứng trong một trong hai trạng thái đó, bạn đã tìm ra vấn đề thứ tự chứ chưa sửa nó.