Đây là bên trong một nftables kịch bản tải với lệnh nft -f. Các nft từ không có ý nghĩa bên trong và không nên xuất hiện. Nhưng có 1/2 vấn đề khác ở cùng một nơi. Vì vậy, hãy xem:
Xung quanh dòng nft lệnh phàn nàn có:
chuỗi về phía trước {
loại bộ lọc hook ưu tiên về phía trước 0;
nft add rule inet filter forward ct status dnat accept;
giảm chính sách;
}
nft bị gỡ bỏ,
đã ở trong một bộ lọc inet về phía trước (chuỗi) khối
Cho nên thêm bộ lọc inet quy tắc về phía trước cũng phải được loại bỏ. Trên thực tế ; là không cần thiết vì có một dòng mới sau.
trạng thái ct dnat chấp nhận
giảm chính sách; phải được đặt với định nghĩa chuỗi cơ sở
Lần này với sự bắt buộc của nó ; một phần của cú pháp. các chính sách từ khóa là một phần của chuỗi Định nghĩa, không phải là một phần của quy tắc Định nghĩa. Mặc dù điều này dường như hiện được chấp nhận tách biệt khỏi định nghĩa chuỗi cơ sở của nó theo các quy tắc giữa, nhưng đó không phải là điều cần dựa vào: điều này có thể thay đổi trong bản phát hành sau này.
Nhận xét tương tự áp dụng cho đầu ra chuỗi: không tách rời chính sách chấp nhận; từ định nghĩa chuỗi cơ sở của nó để sau này bạn sẽ không chèn nhầm các quy tắc vào giữa.
Các phía trước chuỗi cuối cùng nên được thay thế bằng:
chuỗi về phía trước {
loại bộ lọc hook ưu tiên về phía trước 0; giảm chính sách;
trạng thái ct dnat chấp nhận
}
Cú pháp đúng, nhưng không thực sự thú vị, là xác định quy tắc không nằm trong khối, mà hoàn toàn nằm ngoài cấu trúc, ở cuối tập lệnh như thế này:
chuỗi về phía trước {
loại bộ lọc hook ưu tiên về phía trước 0; giảm chính sách;
}
}
thêm quy tắc bộ lọc inet chuyển tiếp trạng thái ct dnat chấp nhận
Dù sao thì bộ quy tắc danh sách nft sau đó sẽ hiển thị nó trở lại như trước trong bộ lọc inet về phía trước khối chuỗi.
Ghi chú:
trong khi nó ổn để sử dụng giao thức ip icmp, nó không ổn để sử dụng ip6 nexthdr ipv6-icmp
lý do là trái ngược với IPv4 trong đó giao thức trong tiêu đề IPv4 luôn là giao thức lớp 4, của IPv6 tiêu đề tiếp theo không phải lúc nào cũng là tiêu đề lớp 4 (icmp, udp, tcp...): thay vào đó, nó có thể là một Tiêu đề mở rộng xuất hiện giữa tiêu đề IPv6 và tiêu đề lớp 4 (cuối cùng). Trong trường hợp này, quy tắc sẽ không khớp.
Hệ điều hành đã xác định gói này thuộc về giao thức lớp 4 nào, vì vậy thông tin có sẵn dưới dạng thông tin meta thay vì thông tin nội dung gói: meta l4proto ipv6-icmp.
Đây cũng là tài liệu trong trang người đàn ông:
Biểu thức này đề cập đến các trường tiêu đề ipv6. Thận trọng khi sử dụng
ip6 nexthdr, giá trị chỉ đề cập đến tiêu đề tiếp theo, tức là ip6 nexthdr tcp sẽ chỉ khớp nếu gói ipv6 không chứa bất kỳ
tiêu đề mở rộng. Các gói bị phân mảnh hoặc ví dụ: chứa một
tiêu đề mở rộng định tuyến sẽ không được khớp. Vui lòng sử dụng meta l4proto
nếu bạn muốn khớp tiêu đề truyền tải thực và bỏ qua bất kỳ
thay vào đó là các tiêu đề mở rộng bổ sung.
Nhưng trên thực tế, vì cùng một dòng có bao gồm một loại icmpv6 ... dòng, điều này đã lọc giao thức lớp 4 để phù hợp với ICMPv6, đồng thời việc sử dụng ICMPv6 hoàn toàn đặt giao thức lớp 3 để phù hợp với IPv6: không có gì là cần thiết để làm cho nó đúng.
Tương tự như vậy, dòng trước có thể làm mà không cần giao thức ip icmp vì những lý do tương tự (nhưng hành vi hiện tại của nó vẫn ổn).
Dòng:
ip6 nexthdr icmpv6 icmpv6 loại echo-request tốc độ giới hạn trên 10/giây bùng nổ 4 gói bị rớt
phải được thay thế đơn giản bằng:
tốc độ giới hạn yêu cầu tiếng vang loại icmpv6 trên 10/giây bùng nổ 4 gói bị rớt
(không cần chuẩn bị trước meta nfproto ipv6 meta l4proto icmpv6 )
TFTP
các quy tắc giống hệt nhau chỉ với các giá trị cổng khác nhau có thể được nhân tố hóa bằng cách sử dụng bộ ẩn danh. nftables phiên bản >= 1.0.2 thậm chí còn có -o (tối ưu hóa) tùy chọn để thử và làm điều này tự động.
