Как пометить входящий запрос iptables с неизвестного MAC-адреса меткой 99 с помощью conntrack

Как пометить входящий запрос iptables с неизвестного MAC-адреса меткой 99 с помощью conntrack

Мои правила iptables работают без сбоев уже много лет, но после того, как я разрешил доступ всем доверенным MAC-адресам:

/sbin/iptables -A INPUT -m mac --mac-source $MAC -j ACCEPT
/sbin/iptables -A FORWARD -m mac --mac-source $MAC -j ACCEPT

Я пытаюсь отметить другие MAC-адреса, например:

/sbin/iptables -A PREROUTING -t mangle -i $INT_DEV -p tcp --dport 80 -j MARK --set-mark 99

но когда я пытаюсь прочитать этот адрес сейчас, делая это,
conntrack -L | grep "src=10.1.1.234"
я не вижу нигде моего неизвестного 10.1.1.234 freeloader...
Тем не менее, я хочу продолжить в iptables перенаправлять моего freeloader на страницу входа с помощью

/sbin/iptables -t filter -A FORWARD -m mark --mark 99 -j DROP```  
And obviously it doesn't work because I can't even see it from my conntrack listing.  
What am I doing wrong here..?

решение1

Есть разница междупакетМарк, он же простоотметка,отметка брандмауэраилиfwmark, и метка входа conntrack, также известная какctmark,метка соединенияиликоннмарк: первый прикреплен к пакетуskbuff, последний прикрепляется кзапись conntrack. Существуют различныеiptables мат-чесисмола-получаетдля обоих, включая способыпередать отметку из пакета в запись соединенияилиот входа в соединение до пакета.

Здесь нет необходимости использовать этот знак сconntrackдля этого случая и conntrack -Lпросто не является правильным инструментом для отображения отброшенного пакета (см. последний абзац). При использовании варианта iptables-nftсамый простой способ увидеть помеченные пакеты для целей отладки (иначе простое использование -j LOGдобавило бы метку пакета в его журналы) - это отследить их и использовать xtables-monitor --traceдля отображения их судьбы ( iptables-legacyотправит это в журналы ядра и может легко затопить журналы, кроме того, он не очень хорошо работает с сетевыми пространствами имен: это редкое несовместимое изменение между вариантами -legacy и -nft).

Итак, один из возможных примеров:

iptables -A PREROUTING -t mangle -i $INT_DEV -p tcp --dport 80 -j MARK --set-mark 99
iptables -A PREROUTING -t mangle -m mark --mark 99 -j TRACE

[...]

iptables -A FORWARD -m mark --mark 99 -j DROP

Подробную судьбу всех таких помеченных пакетов между -j TRACEи -j DROP(или -j ACCEPTплюс всю дальнейшую обработку для этих избранных) теперь можно проследить очень подробно с помощью:

xtables-monitor --trace

Чтобы ограничить многословие, можно отслеживать только пакеты, начинающие новый поток, изменив TRACEправило следующим образом:

iptables -A PREROUTING -t mangle -m mark --mark 99 -m conntrack --ctstate NEW -j TRACE

Кроме того: первый пакет такого потока действительно запускает созданиеconntrackзапись, которая (даже без отметки) обычно будет видна в режиме событий с использованием conntrack -E -p tcp --dport 80. Но когда этот пакет отбрасывается, предварительная запись conntrack никогда неподтвержденныйи событие никогда не будет доступно для conntrack. Хотя оно будет невидимым с conntrackкомандой, оно все равно будет видно в правилах, используемых -m conntrack --ctproto tcp --ctorigdstport 80до того, как оно будет сброшено. Любая последующая попытка снова будет первым пакетом, который создаст предварительную запись, которая не будет подтверждена, поскольку пакет был сброшен и т. д.

Поэтому его conntrackможно использовать только для отображения потоков, первый пакет которых не был потерян, в противном случае поток для него не будет доступен.

Связанный контент