Маршрутизований чи мостовий VPN: обирайте за тим, до чого клієнт мусить дістатися

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

Дві заявки, які на стійці виглядають однаково

Вимога працівника — це послуга, доступна через IP з пристрою, яким ви не керуєте. Вимога інженера — на рівні каналу: прилад очікує побачити кадри Ethernet і виявлення широкомовленням, а можливо, і DHCP із того сегмента, у якому він себе вважає.

Це різні питання, і відповідь на обидва мостом без причини розширює доступ працівника на всю офісну LAN.

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

Маршрут вужчий за членство в LAN

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

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

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

Міст змінює питання про допуск

Мостове з’єднання об’єднує фізичний інтерфейс і пристрій TAP у програмний комутатор, тож віддалені пристрої приєднуються до того самого широкомовного домену. Це реальна можливість і реальний ризик: віддалений пристрій уже не маршрутизований гість, він учасник.

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

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

Фільтрування є в обох топологіях

Міст не є за своєю природою нефильтрованим, а маршрут не є за своєю природою безпечним. Фільтрування мостів у Linux має власні гачки й власний синтаксис правил, і правило, написане для маршрутизованого пересилання IP, не застосовується автоматично до кадрів моста.

Перевірте, що платформа справді підтримує, перш ніж обіцяти кордон:

bridge link show
nft list ruleset

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

Доведіть кордон трьома спробами

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

Запустіть дозволений і заборонений шлях з одного й того самого клієнта і запишіть обидва:

curl -sS -o /dev/null -w "%{http_code}" http://10.20.0.10/health
ip route get 10.20.0.10
ip route get 10.30.0.5

Для моста додайте перевірки рівня каналу: чи проходить дозволений трафік виявлення, чи надходить адресація від передбаченого органу і чи зник тимчасовий учасник після вилучення. Коли звичайний маршрутизований IP уже задовольняє вимогу, приєднання до офісного сегмента Ethernet потребує окремого обґрунтування, і його слід записати до зміни.