SSL VPN чи обгортка TLS? Порівняйте межу, що не витримала

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

Почніть зі з'єднання, яке ви справді налаштували

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

Контракт мережевої схеми інший, і він виражається в маршрутах і політиці, а не в парі портів.

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

Перевірте, до чого підключається обгортка

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

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

openssl s_client -connect wrapper.lab.example:443 -servername wrapper.lab.example -verify_return_error
sudo ss -ltnp | grep 443

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

Перевірте, який трафік несе схема

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

Етикетка продукту не каже, яку з цих моделей ви купили, а номер порту каже ще менше.

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

Перевірте межу відмови, а не етикетку

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

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

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