iptables conntrack модуль: SNAT (или DNAT) состояние вместо ESTABLISHED/RELATED?
Обычный способ - запросить ресурс AAAA:
nslookup -query=AAAA $hostname
И:
dig AAAA $hostname
Благодаря совету @AB относительно ведения журнала я смог провести еще несколько тестов, и вот результаты, а также ответы на мои собственные вопросы, в надежде, что это поможет другим людям, которые, как и я, не найдите что-нибудь в Интернете о состояниях SNATи DNATи/или их способности заменить ESTABLISHED,RELATEDдля сопоставления.
Итак, в умеренно загруженной домашней сети (пара хостов, выходящих в интернет по SNAT, а также несколько виртуальных машин, на которых размещены серверы (HTTP/HTTPS, SMTP, IMAP и т.д. и т.п. )общедоступны по DNAT ), за пять дней я не увидел ни строчки лога о пакете, который был бы в состоянии SNATили DNAT, а также ESTABLISHEDили RELATED.
Таким образом, ответ на вопрос "может ли пакет иметь состояние SNATили DNAT, но не иметь состояния ESTABLISHEDили RELATED" нет .
Поскольку я действительно беспокоился о том, что сопоставление с SNATили DNATвместо ESTABLISHED,RELATEDдля пропуска пакетов в мою локальную сеть может быть слишком разрешительным, поначалу это могло показаться обнадеживающим, но я обнаружил, что это не так. хорошая идея.
На самом деле, похоже, что это, наоборот, менее разрешающее :во время моих тестов с этими правилами, я увидел небольшое, но -не пренебрежимо малое количество пакетов в состоянии RELATED, которые были отброшены, в основном ICMP типа 3, коды 1 и 3 (соответственно хост назначения недоступен и порт назначения недоступен ), поступающие из Интернета и предназначенные для хостов внутри моего ЛВС. Другими словами (, и если я правильно понимаю сети ), мои хосты пытались установить какие-то подключения к Интернету, удаленные маршрутизаторы ответили, что подключение невозможно, и мой собственный хост-брандмауэр/маршрутизатор заблокировал эти ответы.. Это не может быть хорошо.
Таким образом, ответ на основной вопрос «Хорошая ли идея заменить ESTABLISHED,RELATEDна SNATили DNAT» снова нет .
Я бы не стал использовать ваш метод из соображений безопасности. Представьте, что вы переделываете свою сеть и вам больше не нужно использовать SNAT. Что случилось бы? Это очевидная часть. Где-то могут скрываться скрытые проблемы.
Насколько это возможно, правила NAT и правила фильтрации должны оставаться независимыми, если нет веской причины не делать этого. Я не уверен, что у тебя есть веская причина. Хорошей причиной может быть обработка NAT-трафика по-разному, а не NAT-трафика (, например,:сервер DNAT передает услугу другому серверу позади, но не позволяет использовать его в качестве маршрутизатора для прямого доступа к серверу/службе. сзади).
Теперь о вашей заметке :просто разделите задачу на несколько шагов.
Это неверное правило:
iptables -A FORWARD -m conntrack --ctstate SNAT ! --ctstate ESTABLISHED,RELATED -j LOG
можно заменить на:
iptables -N subtest
iptables -A FORWARD -m conntrack --ctstate SNAT -j subtest
iptables -A subtest -m conntrack ! --ctstate ESTABLISHED,RELATED -j LOG
или вместо этого с ВОЗВРАТОМ и обратной логикой:
iptables -N speciallog
iptables -A FORWARD -j speciallog
iptables -A speciallog -m conntrack ! --ctstate SNAT -j RETURN
iptables -A speciallog -m conntrack ! --ctstate ESTABLISHED,RELATED -j LOG
или, используя метки (not, если метки используются где-то еще (и не желая возиться с масками )), вместо этого можно добиться того же:
iptables -A FORWARD -m conntrack --ctstate SNAT -j MARK 1
iptables -A FORWARD -m mark --mark 1 -m conntrack ! --ctstate ESTABLISHED,RELATED -j LOG
Для каждого метода можно легко связать дополнительные тесты (путем увеличения отметки для метода отметки ).