Один мережевий адаптер чи два? Як визначити схему інтерфейсів VPN-сервера

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

Три умови, що це вирішують

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

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

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

Два адаптери залишаються законним вибором, коли фізичні зони, окремі висхідні канали, пропускна здатність або шлях відновлення поза смугою це виправдовують. Це конкретні вимоги, і їх варто сформулювати до того, як хтось замовить обладнання.

Коли служба працює на VPN-хості

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

Дві речі все ж мусять бути правильними: служба повинна слухати на адресі, досяжній із тунелю, а міжмережевий екран хоста повинен приймати трафік, що надходить на інтерфейс тунелю. І те, і те видно в командах нижче.

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

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

Коли призначення розташоване в LAN

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

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

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

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

Чому alias не створює другої зони

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

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

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

Перевірте схему щодо трафіку, який ви дозволяєте

Перелічіть класи трафіку, які сервер має нести: клієнт до хоста, клієнт до LAN, хост до LAN і зашифроване зовнішнє з'єднання. Кожен клас має джерело, призначення та інтерфейс, і схема мусить задовольнити всі чотири одразу. Схема, яка вирішує три з них, зазвичай і породжує заявки.

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

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

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