Як обмежити доступ між двома офісами, з’єднаними через VPN

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

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

Запишіть матрицю, перш ніж торкатися шлюзу

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

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

Застосовуйте там, де пакети розшифровуються

Правила, що дозволяють IKE і ESP, будують лише зовнішній тунель. Внутрішній трафік надходить відкрито на інтерфейс тунелю, і саме там місце списку дозволів: ланцюг пересилання на пристрої, що розшифровує, скидання за замовчуванням, одне правило на рядок матриці. На шлюзах Linux це означає ввімкнене пересилання й правила фільтрації на пристрої тунелю, а не на фізичному каналі, як пояснює посібник strongSwan з пересилання.

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

iptables -A FORWARD -i tun0 -s 10.20.0.0/24 -d 10.10.5.10 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i tun0 -j DROP

NAT і підмережі, що перекриваються, змінюють правила

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

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

Доведіть відмову, а не лише успіх

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

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

Тримайте список живим

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

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