Правила брандмауера лише для NEW не закривають усі шляхи WAN

Відхилення нових вихідних з’єднань на 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

Потім перевірте старий потік поряд із новим. Нова спроба з’єднання й уже активне двобічне передавання поводяться по-різному під цим правилом, і лише перевірка обох показує, яка політика у вас насправді.