Дві групи клієнтів, один сервер: де застосовувати політику

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

Підмережа — це мітка, а не правило

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

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

Виберіть шлях, яким іде трафік між вузлами

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

# peer forwarding inside the daemon: enforce with per-group policy instead of FORWARD rules
client-to-client
# kernel forwarding path: remove the line above, then filter in the forward chain

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

Напишіть матрицю до правил

Коротка матриця легша для огляду, ніж набір правил, і це контракт, який реалізація повинна виконати: вузли однієї групи дозволені, вузли між групами заборонені, обом групам дозволено до одного названого спільного сервісу, усе інше заборонено. Запишіть ці чотири рядки, перш ніж відкрити редактор брандмауера. Рецензент, який не читає синтаксис правил, усе одно може перевірити матрицю. Далі реалізації лишається лише відповідати рядкам.

Тримайте три класи призначення окремо, поки пишете. Сервіс на хості VPN — це локальний вхід, інший клієнт — транзит між вузлами, а машина за шлюзом — інший шлях пересилання. Одне щедре правило може випадково дозволити всі три, і так групова політика перетворюється на пласку мережу із зайвими кроками. Запишіть клас біля кожного рядка, щоб намір пережив наступну правку.

Розмістіть правила там, де вони виживуть

Додавайте рішення в тому самому місці, де обслуговується решта брандмауера, перед будь-яким дозвільним правилом, яке інакше їх поглине. Порядок правил є частиною політики, і правильне правило, поставлене після широкого дозволу, нічого не забезпечує. Запишіть номери правил до і після зміни. Політика, яка існує в редакторі, але не в чинному наборі правил, — це план, а не контроль.

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

Зробіть правила постійними через механізм, що володіє рештою брандмауера, і запишіть матрицю поруч із ними. Незаписана політика знову виводиться з пам'яті під час наступного інциденту, зазвичай кимось у поспіху.

Доведіть це з обох боків

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

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