Чому спільний TAP VPN досі потребує HTTPS на порталі
TAP VPN автентифікує партнера, а не службу за ним. Зберігайте перевірку імені хоста на порталі та ізолюйте сусідів, яким не довіряєте.
Два пристрої мають дійсні облікові дані VPN і спільно використовують один мостовий сегмент Ethernet. Відповідати за портал офісу має лише один із них, а інший досі може претендувати на адресу порталу в цьому сегменті. Тунель зробив свою роботу: він автентифікував обох партнерів і зашифрував кожен шлях до сервера. Чого він не зробив — не засвідчив, кому з них належить ім'я служби, і саме ця прогалина є причиною, чому портал досі потребує дійсного сертифіката.
Що VPN насправді автентифікує
Рукостискання VPN відповідає на одне питання: який партнер завершив цей тунель і з яким ключовим матеріалом. Ця відповідь стосується кожного партнера й кожного з'єднання і нічого не каже про служби, які партнер потім надає. У сегменті TAP партнер навіть не одна адреса, бо може представити будь-який MAC і будь-який IP, який міст готовий вивчити. Автентифікація зупиняється на кінці тунелю, а не в застосунку.
Розділіть три питання, а не зливайте їх в одне. Кожне має свій механізм і свій спосіб відмови.
| Question | Answered by |
|---|---|
| Which peer sent this packet? | VPN transport authentication |
| Which device owns this IPv4 address? | ARP, trusted only as far as the segment |
| Which service am I talking to? | Application TLS and hostname validation |
Розгортання може мати ідеально автентифікований тунель і цілком неавтентифіковану службу за ним. Також може мати перевірений сертифікат на хості, адресу другого рівня якого вимагає інший партнер, і тому обидва засоби контролю мають бути в проєкті, а не один замість іншого. Таблиця — це весь аргумент у трьох рядках.
ARP у спільному сегменті — не довідник
ARP зіставляє адресу IPv4 з MAC у локальному каналі й приймає відповіді від будь-кого в цьому каналі. У поблажливому мостовому сегменті партнер може вимагати адресу, що належить іншому пристрою, а міст пересилає кадри тому, хто відповів останнім. Шифрування кожного клієнтського шляху до сервера цього не змінює, бо кадри розшифровуються до того, як досягнуть мосту. Межа довіри ARP — сегмент, а не тунель.
Подивіться, чого насправді навчився хост: ip neigh show показує поточні зіставлення та їхній стан, а запис, який під час нормальної роботи перемикається між двома адресами MAC, — це симптом, який варто розслідувати, а не ігнорувати. У здоровому малому сегменті такі записи довго залишаються стабільними.
Ізоляція партнерів і політика мосту існують саме для цього випадку. Маршрутизована схема зазвичай є кращою відповіддю, коли служба лише IP і пристрої не мають жодних причин бачити кадри одне одного.
Тримайте перевірку сертифіката там, де є служба
TLS застосунку відповідає на питання, на яке тунель не здатен: це та служба, до якої я хотів потрапити. Браузер звіряє ім'я хоста із сертифікатом, і ця перевірка — єдина частина ланцюга, яка називає портал, а не партнера.
Вивчіть, що подає сервер, перш ніж вирішити, що попередження косметичне. openssl s_client -connect portal.example.internal:443 -servername portal.example.internal друкує ланцюг і альтернативні імена суб'єкта. Якщо введеного імені немає в цьому списку, попередження правильне і виправляти треба сертифікат. Навчання користувачів проходити повз нього перетворює робочий контроль на оздоблення.
Посібник з мостування OpenVPN описує модель Ethernet і параметри політики навколо неї, і це правильне джерело того, що сегмент має дозволяти. Прочитайте його, перш ніж послаблювати правило мосту, бо описана там модель — це те, що передбачає кожна перевірка вище.
Вирішіть, чи повинні ці партнери взагалі ділити сегмент
Найдешевше виправлення — зазвичай перестати ділити другий рівень, коли вимога лише в доступності IP. Маршрутизований VPN дає кожному клієнту власну адресу, прибирає спільний домен широкомовлення і перетворює трафік між партнерами на політичне рішення, а не типове значення. Тоді портал має одну адресу для захисту і жодних сусідів, які можуть на неї претендувати.
Якщо сегмент має залишитися, перевірте налаштування на боці сервера, яке дозволяє клієнтам досягати один одного: grep -n client-to-client /etc/openvpn/server.conf. Коли його вимкнено, клієнтський трафік іде через сервер і може фільтруватися там. Коли його ввімкнено, партнери обмінюються кадрами безпосередньо через міст, а вашими точками фільтрації є міст і міжмережевий екран хоста.
Запишіть, на які захисти кожен хост насправді покладається: автентифікацію тунелю, ізоляцію сегмента або TLS застосунку. Хост, який покладається на всі три, у порядку. Хост, який покладається на першу і припускає, що дві інші прийшли разом із нею, — це той, хто зрештою віддає неправильний вміст.