Это внутри nftables сценарий загружается с помощью команды нфт -ф. нфт слово не имеет смысла внутри и не должно появляться. Но есть 1 1/2 других проблем в том же месте. Итак, давайте посмотрим:
Вокруг линии нфт команда жалуется, что есть:
цепочка вперед {
type filter hook forward Priority 0;
nft добавить правило inet filter forward ct status dnat accept;
падение политики;
}
нфт быть удалены,
уже внутри инет фильтр вперед (цепной блок
Так добавить правило инет фильтр вперед также должны быть удалены. На самом деле ; является излишним, потому что после него идет новая строка.
кт статус днат принять
падение политики; должен быть помещен с определением базовой цепи
На этот раз с обязательным ; часть синтаксиса. в политика ключевое слово является частью цепь определение, не часть правило определение. Хотя в настоящее время это кажется принятым, отделенным от определения базовой цепочки правилами между ними, на это нельзя полагаться: это может измениться в более позднем выпуске.
То же замечание относится и к вывод цепь: не разделять политика принять; из его определения базовой цепочки, поэтому вы не будете вставлять правила между ними по ошибке позже.
вперед chain в конце следует заменить на:
цепочка вперед {
type filter hook forward Priority 0; падение политики;
кт статус днат принять
}
Что было бы правильным синтаксисом, но не очень интересным, так это определить правило не внутри блоков, а полностью вне структур, в конце скрипта вот так:
цепочка вперед {
type filter hook forward Priority 0; падение политики;
}
}
добавить правило inet filter forward ct status dnat accept
Тем не мение набор правил списка nft затем отобразит его обратно, как и раньше, в инет фильтр вперед цепной блок.
Примечания:
пока можно использовать ip-протокол icmp, это не нормально использовать ip6 nexthdr ipv6-icmp
причина в том, что в отличие от IPv4, где протокол в заголовке IPv4 всегда является протоколом уровня 4, протокол IPv6 следующий заголовок не всегда является заголовком уровня 4 (icmp, udp, tcp...): вместо этого может быть Заголовок расширения появляется между заголовком IPv6 и заголовком уровня 4 (последний). В этом случае правило не будет совпадать.
ОС уже определила, к какому протоколу уровня 4 принадлежит этот пакет, поэтому информация доступна в виде метаинформации, а не информации о содержимом пакета: мета l4proto ipv6-icmp.
Это тоже задокументировано на странице руководства:
Это выражение относится к полям заголовка ipv6. Осторожность при использовании
ip6 некстхдр, значение относится только к следующему заголовку, т.е. ip6 некстхдр tcp будет соответствовать только в том случае, если пакет ipv6 не содержит
заголовки расширения. Пакеты, которые фрагментированы или, например, содержать
заголовки расширения маршрутизации не будут сопоставляться. Пожалуйста, используйте мета l4proto
если вы хотите сопоставить реальный транспортный заголовок и игнорировать любые
вместо этого дополнительные заголовки расширения.
Но на самом деле, поскольку в той же строке есть тип icmpv6... строка, это уже фильтрует протокол уровня 4, чтобы он соответствовал ICMPv6, и в то же время использование ICMPv6 неявно устанавливает протокол уровня 3 для соответствия IPv6: вообще ничего не нужно, чтобы сделать это правильно.
Точно так же предыдущая строка может обойтись без ip-протокол icmp по тем же причинам (но его текущее поведение все еще в порядке).
Линия:
ip6 nexthdr icmpv6 тип icmpv6 ограничение скорости эхо-запроса более 10/секунду всплеск 4 пакета отбрасываются
необходимо заменить просто на:
icmpv6 тип ограничения скорости эхо-запроса более 10 пакетов в секунду 4 пакета отбрасываются
(без необходимости предварять мета nfproto ipv6 мета l4proto icmpv6 )
TFTP
TFTP использует только UDP
TCP-порт 69 никогда не используется, поэтому для его разрешения не требуется правило.
TFTP и межсетевой экран с отслеживанием состояния
TFTP это протокол столь же сложный, как FTP для брандмауэров. После первоначального запроса сама передача данных больше нигде не использует UDP-порт 69. Адекватное использование Помощник по подключению к TFTP с дополнительными правилами (которые должны автоматически загружать nf_conntrack_tftp модуль ядра), вероятно, должен быть необходим, если только не используется устаревшая настройка sysctl. net.netfilter.nf_conntrack_helper был включен обратно.
Это действительно стало бы не по теме, чтобы обсудить это здесь. Смотрите начало (только) моего ответа на CentOS 8 в качестве маршрутизатора NAT с nft и firewalld — как заставить его проходить TFTP? иметь пример набора правил TFTP, который можно скопировать для замены Пример FTP в вики nftables.
идентичные правила с разными значениями портов могут быть факторизованы с помощью анонимные наборы. nftables версия >= 1.0.2 даже имеет -о (оптимизировать) вариант чтобы попытаться сделать это автоматически.
