Один сервер TAP чи кілька? Клієнти OpenVPN на мосту

Кілька клієнтів TAP не потребують по одному серверному процесу, одному порту UDP і одному пристрою TAP на хості для кожного. Один сервер OpenVPN у режимі Ethernet може прийняти багато автентифікованих клієнтів і приєднати їх до одного мосту, і це документований спосіб розширити сегмент канального рівня 2. Схема з одним процесом — та, яку описує посібник, і зазвичай це правильне значення за замовчуванням.

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

Дві архітектури, а не два налаштування

Розгортання з маршрутизованим TUN дає кожному клієнту з’єднання «точка-точка» в домен маршрутизації сервера. Широкомовлення зупиняється на сервері, клієнти не бачать кадрів один одного, а трафік між клієнтами, якщо він є, треба явно маршрутизувати й фільтрувати.

Розгортання з мостовим TAP робить клієнтів членами одного сегмента Ethernet. Вони бачать широкомовлення, можуть знаходити один одного через ARP і для розділення покладаються на політику мосту та брандмауера, а не на маршрутизацію. Це корисно, коли клієнти мають виглядати так, ніби вони підключені до того самого комутатора.

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

Що робить помічник server-bridge

Помічник server-bridge налаштовує режим Ethernet для кількох клієнтів. Його форма з пулом адрес бере шлюз, маску мережі та виділений діапазон усередині мостової підмережі, наприклад шлюз 192.168.50.1 із пулом від 192.168.50.160 до 192.168.50.199.

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

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

Ізоляція не визначається кількістю процесів

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

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

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

Коли кілька процесів усе ж виправдані

Окремі процеси можна виправдати експлуатаційними потребами: різними системами автентифікації, різними центрами сертифікації, окремими циклами оновлення або несумісними наборами параметрів. Це реальні причини, і вони не залежать від кількості клієнтів.

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

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

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