Возможен ли такой вариант
Внимательней изучайте работу iptables.
Правила делятся на терминирующие и нетерминирующие (второе определение может быть не верным, но в данном случае отражает суть).
Если срабатывает терминирующее правило, то прохождение пакета по цепочке прекращается и переходит в следующую цепочку.
К терминирующим относятся (не все перечислены) - ACCEPT, DROP, REDIRECT, REJECT, DNAT, SNAT, MASQUERADE...
К нетерминирующим (тоже далеко не все) - LOG, TCPMSS, MARK ... больше на вскидку не вспомню
Пример (ваще больной на всю голову,
не повторять): имеем 2 интерфейса: eth0,1. Хотим чтобы все клиенты eth0 ходили везде и вся, а со стороны eth1 пусть отдыхают.
-P FORWARD DROP (а чё? всё по фен-шую)
-A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT (пропускаем установленные соединения, чтоб не морочиться)
-A FORWARD -i eth0 -j ACCEPT
ОК. вроде всё отлично. Система ниппель: туда дуй, оттуда фиг вам.
Тут приходит ещё одна сетка и добавляется eth2 из директорского кабинета, в которую никто не должен ходить, а директор... ну на то он и директор, чтобы всё знать и всех иметь.
Да нет проблем, добавляем:
-A FORWARD -i eth2 -j ACCEPT (дорогу
королю директору)
А обратно никто не пойдёт, ведь дефолтное правило DROP
И... какие-то грабли: директор орёт, что его
порнуху документы кто-то смотрит без его ведома.
Разберёмся и смотрим, что-же у нас там в таблице.
И чтобы не плодить сразу представляем, как злостный манагер из сети за eth0 лезет в комп директора.
-P FORWARD DROP (ну это сработает, если ни одно правило не сработает и мысленно его забываем до конца цепочки, если дойдёт дело)
-A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT (манагер тока полез, потому никаких соединений пока нет)
-A FORWARD -i eth0 -j ACCEPT (так, захожу через eth0, потому я могу идти дальше)
Вот именно на этом правиле пакет покинет цепочку с переходом в следующую, то есть продолжит путь к цели,
а до запрещающего правило дело и не дошло...
Бороться с таким явлением можно по разному. Но самый простой и надёжный способ от подобных граблей замедленного действия, ИМХО, более чётко ставить условия правил. Например, самое простое, было изначально указать не только входной интерфейс, но и через который должен выходить разрешённый траффик.
-A FORWARD -i eth0 -o eth1 -j ACCEPTВсё. Добавление любого интерфейса не добавит полномочий клиентам сети eth0.
Ну это так... в качестве трололо. Может и не стоило так много писать. Но надеюсь какому-нибудь новичку чуть больше отодвинул завесу "секретов" iptables