netfilter / iptables: чому б не використовувати необроблену таблицю?

У Linux ми зазвичай використовуємо таблицю «фільтр» для загальної фільтрації:

iptables --table filter --append INPUT --source 1.2.3.4 --jump DROP
iptables --table filter --append INPUT --in-interface lo --jump ACCEPT

Відповідно до діаграми netfilter нижче, пакети спочатку проходять через "сировину" таблиці:

Тож ми можемо написати:

iptables --table raw --append PREROUTING --source 1.2.3.4 --jump DROP
iptables --table raw --append PREROUTING --in-interface lo --jump ACCEPT

• пакети обробляються швидше, без необхідності переходити через conntrack + mangle + nat + route. Так трохи менше використовується процесор / пам'ять (і, в свою чергу, легенько компенсується тим, що модуль iptable_raw повинен бути завантажений)
• лише одне правило, якщо поле також є маршрутизатором (очевидно, не для всіх правил, очевидно), тому що немає необхідності додавати те саме правило для фільтра / вперед

Я робив лише швидкі тести, і це працює чудово.
В документах, які я знайшов, завжди описується сирий стіл, який слід використовувати у суворих випадках. Але ніхто не дає навіть найменшого виправдання.

Питання: чи є причини, щоб не використовувати грубу таблицю, крім догматичних?

Від iptables man :

raw: This table is used mainly for configuring exemptions from connection
     tracking in combination with the NOTRACK target. It registers at the
     netfilter hooks with higher priority and is thus called before
     ip_conntrack, or any other IP tables.
     It  provides the following built-in chains:

     - PREROUTING (for packets arriving via any network interface)
     - OUTPUT (for packets generated by local processes)

Аналіз :

Отже, таблиця RAW перебуває до початку випуску, і вона була розроблена з метою, яка повинна використовуватися для встановлення позначки NOTRACK на пакетах, які ви не хочете відслідковувати в netfilter.

Цілі -j не обмежуються лише NOTRACK, так що так, ви фільтруєте пакети в необробленій таблиці з перевагами менше споживання процесора / пам'яті.

Найчастіше серверам не потрібно відстежувати всі з'єднання. Відстеження вам потрібно лише в тому випадку, якщо вам потрібно фільтрувати пакети в iptables на основі попередніх встановлених з'єднань. На серверах, які виконують лише просту мету, наприклад, з відкритим лише портом 80 (а може бути, 21), цього не потрібно. У цих випадках ви можете відключити відстеження з'єднання.

Однак якщо ви намагаєтеся запустити NAT-роутер, все стає дещо складним. Для того, щоб NAT щось робити, вам потрібно відслідковувати ці з'єднання, щоб ви могли доставляти пакети із зовнішньої мережі до внутрішньої мережі.

Якщо для NOTRACK встановлено ціле з'єднання, ви також не зможете відслідковувати пов’язані з'єднання, а також допоміжні програми conntrack і nat просто не працюватимуть для відслідковуваних з'єднань, а також пов'язані помилки ICMP. Іншими словами, вам доведеться відкрити їх вручну. Що стосується складних протоколів, таких як FTP та SCTP та інших, це може бути дуже важким для управління.

Користувачі :

Одним із прикладів може бути, якщо у вас є маршрутизатор з великою торгівлею людьми, на якому ви хочете брандмауер вхідного та вихідного трафіку, але не маршрутизований трафік. Потім ви можете встановити позначку NOTRACK для ігнорування пересланого трафіку для економії процесорної потужності.

Інший приклад, коли NOTRACK можна використовувати, якщо у вас веб-сервер з високою торгівлею людьми, ви можете встановити правило, яке обертається відстеженням для порту 80 на всі IP-адреси в локальній власності, або ті, які фактично обслуговують веб-трафік. Тоді ви зможете насолоджуватися відстежувальним відстеженням для всіх інших служб, за винятком веб-трафіку, який може заощадити деяку потужність обробки у вже перевантаженій системі.

Приклад -> працює-a-semi-stateless-linux-router-for-private-network

Висновок : Немає вагомих причин не використовувати необроблену таблицю, але є деякі причини, щоб бути обережними під час використання цілі NOTRACK у сирої таблиці.