Netfilter не блокирует пакеты, как должно?

В целях тестирования я создал следующий nftables.conf на машине с ядром 6.1.0 и nftables 1.0.6:

table netdev t_NETDEV_enp0s3 {
  chain enp0s3-ingress-filter {
    type filter hook ingress device "enp0s3" priority filter; policy drop;
    ether type 0x0806 arp ptype 0x0800 accept
    ether type 0x0800 accept
    log prefix "foo: " drop
  }
} 

table ip t_IP {

  chain prerouting-nat {
    type nat hook prerouting priority dstnat; policy drop;
    log prefix "ip4-prerouting-nat:" drop;
  }
  chain prerouting-filter {
    type filter hook prerouting priority filter; policy drop;
    log prefix "ip4-prerouting-filter:" drop;
  }

  chain input-nat {
    type nat hook input priority dstnat; policy drop;
    log prefix "ip4-input-nat:" drop;
  }
  chain input-filter {
    type filter hook input priority filter; policy drop;
    log prefix "ip4-input-filter:" drop;
  }

  chain forward-filter {
    type filter hook forward priority filter; policy drop;
    log prefix "ip4-forward-filter:" drop;
  }

  chain output-nat {
    type nat hook output priority srcnat; policy drop;
    log prefix "ip4-output-nat:" drop;
  }
  chain output-filter {
    type filter hook output priority filter; policy drop;
    log prefix "ip4-output-filter:" drop;
  }
  chain output-route {
    type route hook output priority mangle; policy drop;
    log prefix "ip4-output-route:" drop;
  }

  chain postrouting-nat {
    type nat hook postrouting priority srcnat; policy drop;
    log prefix "ip4-postrouting-nat:" drop;
  }
  chain postrouting-filter {
    type filter hook postrouting priority filter; policy drop;
    log prefix "ip4-postrouting-filter:" drop;
  }
}

Я понимаю, что эти правила не имеют смысла; они являются частью тестового сценария.

Когда они активны, я ожидаю, что никакие пакеты IPv4 не смогут попасть к любому приложению, работающему на машине. Согласно мануалу nft (в разделе “VERDICT STATEMENT”) (выделено мной):

accept Завершить оценку набора правил и принять пакет. Пакет всё ещё может быть отброшен позже другим крюком, например, если он принят в крюке forward, его всё равно можно отбросить позже в крюке postrouting, или другой базовой цепочкой forward, которая имеет более высокий приоритет и оценивается позже в процессе обработки.

drop Завершить оценку набора правил и отбросить пакет. Отбрасывание происходит мгновенно, дальнейшие цепочки или крюки не оцениваются. Невозможно принять пакет позже в другой цепочке снова, так как они больше не оцениваются для пакета.

Однако пакеты действительно поступают в приложения на этой машине. Например, там работает SSH сервер, и я могу удаленно подключиться через этот сервер по сети. Согласно моему пониманию, этого не должно быть возможным по следующим причинам:

• Все цепочки в t_IP имеют политику drop и не содержат никаких правил, так что они должны вести себя так, как если бы было установлено явное решение drop для всех пакетов, проходящих через эту цепочку.

• Я настроил одну цепочку, как описано выше, для каждой возможной комбинации (согласно мануалу nft) типа крюка и цепочки, которая поддерживается в IP семье.

• Это означает, что каждый пакет IPv4 должен проходить через как минимум одну из этих цепочек после прохождения через цепочку ingress, поскольку ingress – это первый крюк, а другие крюки обрабатываются позже (согласно документации).

• Это в свою очередь означает, что каждый пакет IPv4 должен быть отброшен (если цитата выше не является ошибочной), потому что решение drop в каждой цепочке в t_IP перекрывает решение accept из цепочки ingress.

Дополнительные подсказки:

• IPv6 полностью отключен на этой машине (с помощью обычного параметра ядра).
• enp0s3 назначен единственный IP адрес.
• SSH сервер слушает только на этом IP адресе.
• Следовательно, невозможно добиться доступа к SSH серверу другим способом, кроме как через enp0s3 / IPv4.

Кто-нибудь может объяснить, почему сервер SSH доступен, то есть почему пакеты не отбрасываются до достижения локальных приложений?