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

Назва зони нічого не шифрує і не автентифікує користувача. Вона лише групує інтерфейси для моделі політик міжмережевого екрана.

Що насправді контролює членство в зоні

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

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

Саме ця відмінність робить окрему зону корисною: можна явно вказати кожен напрямок і кожну роль. Записуйте напрямок біля кожного правила.

Рішення перше: вхід, пересилання чи обидва

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

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

Рішення друге: які ресурси потрібні віддаленим клієнтам

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

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

Якщо дозволене призначення може пересилати далі, межа зони закінчується на міжмережевому екрані, а не на тому, що призначення робить далі.

Рішення третє: як ви доведете межу

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

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

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

Схожі статті