Правила брандмауэра только для NEW не закрывают все пути WAN
Отклонение подключений NEW оставляет установленные потоки и ответы нетронутыми. Прочитайте состояние conntrack, порядок правил и исключения, прежде чем называть политику закрытой.
Отклонение новых исходящих подключений на WAN выглядит как политика, закрывающаяся при сбое, но это более узкое обещание, чем кажется. Пакеты, принадлежащие уже существующим потокам, под неё не подпадают, как и многие ответы. Этот пробел легко упустить, потому что правило читается так, будто оно охватывает интерфейс, а не одно состояние соединения на нём. А чтение совпадения состояния как приговора и создаёт ложное чувство закрытости.
Состояние — это условие совпадения, а не приговор
Отслеживание соединений классифицирует пакеты по тому, что брандмауэр уже видел, а не по тому, что считает приложение. Поток, наблюдаемый в обоих направлениях, считается установленным, и его последующие пакеты остаются установленными даже тогда, когда маршрут под ним меняется с туннеля на обычную восходящую линию. Ответ на входящее соединение тоже может быть установленным трафиком. Эти пакеты никогда снова не становятся новыми.
Поэтому правило, ограниченное новыми соединениями, не может доказать, что каждый защищённый пакет блокируется. Оно оставляет остальные состояния тому, что с ними делает остальной набор правил, а это может быть разрешение, размещённое раньше в цепочке.
Читайте правило в его окружении
Широкое разрешение для установленного и связанного трафика, размещённое перед блокировкой, пропускает пакет раньше, чем блокировка вообще оценивается. Удаление условия состояния из более позднего правила этого не изменит, потому что оценка до него никогда не доходит. Результат определяет порядок, а то, какие пакеты доходят до этого порядка, определяет совпадение состояния.
Проверяйте действующий набор правил, а не файл, который вы правили, включая переходы в другие цепочки и всё, что создаёт платформа. На маршрутизаторе под управлением iptables перечисление цепочки показывает определения правил, и цепочки, на которые оно ссылается, тоже нужно проследить. Родной системе nftables требуется проверка собственного набора правил и приоритетов хуков, так как прошивка редко создаёт одинаковые цепочки.
Счётчики показывают, какое правило действительно сработало, и они обычно информативнее перехвата пакетов, сделанного после решения. Правило с нулевым счётчиком не было достигнуто, что бы ни подсказывало его положение.
Выражайте запрет независимо от состояния
Если группа клиентов никогда не должна выходить в интернет вне туннеля, скажите это прямо, а не приближайте одним состоянием. Правило должно выбирать по источнику, выходу и назначению, не завися от состояния соединения, и должно стоять там, где никакое более раннее разрешение не может его обойти. Тогда административный доступ и исключения для локальной сети получают свои явные правила, и замысел виден в политике.
Выбор reject вместо drop меняет то, как отказывает совпавший трафик, и не расширяет набор пакетов, которые выбирает правило. Отклонённое соединение и тихий тайм-аут — разные симптомы, указывающие на один и тот же выбор.
Политика, которая намеренно разрешает ответы на доступ, инициированный извне через WAN, имеет право на существование. Просто описывайте её именно так, а не подавайте как полную изоляцию только через туннель.
Проверьте, кто на самом деле в группе
Пример охватывает пересылаемый трафик IPv4 из одного префикса через один интерфейс. Он ничего не говорит об IPv6, второй восходящей линии или трафике, который создаёт сам маршрутизатор. Маршрутизатор, работающий как DNS-резолвер, отправляет свои собственные запросы вверх, и они вообще не проходят через цепочку forward.
Убедитесь, что защищённые клиенты по-прежнему имеют адреса внутри выбранного префикса, потому что устройство, вышедшее за его пределы, оказывается прямым случайно, а не по политике. Расширение блокировки на всю LAN без пересмотра схемы исключений тоже обычно убирает ваш собственный административный путь.
iptables -S FORWARD
iptables -L FORWARD -v -n
cat /proc/net/nf_conntrack | grep -c ESTABLISHED
Затем проверьте старый поток рядом с новым. Новая попытка соединения и уже активная двусторонняя передача ведут себя по-разному под этим правилом, и только проверка обоих показывает, какая политика у вас на самом деле.