Почему SSL VPN и VPN «сайт-сайт» не противоположности
SSL VPN и VPN «сайт-сайт» описывают разные оси: кто подключается к сети и как строится туннель. Называть оба одновременно — категориальная ошибка.
Попросите двух администраторов описать одну и ту же VPN, и один может ответить «SSL VPN», а другой сказать «сайт-сайт», будто это конкурирующие пункты меню. Это ответы на разные вопросы, и обращение с ними как с альтернативами порождает сравнения, которые невозможно разрешить. Один ярлык говорит, какие конечные точки соединяются; другой — что несёт трафик между ними. Держите оси раздельно, и большая часть спора исчезнет.
Два ярлыка, два отдельных вопроса
Топология отвечает, кто к чему подключается. Проект удалённого доступа подключает отдельных пользователей или устройства к шлюзу, обычно с идентичностью на пользователя и пулом адресов. Проект «сайт-сайт» соединяет две сети через шлюзы, поэтому интересна идентичность партнёрского шлюза, а не человека за клавиатурой. Это разные эксплуатационные задачи — от планирования адресов до того, кто может отозвать доступ в 2 часа ночи.
Механизм отвечает, как строится и аутентифицируется туннель. IPsec с IKEv2, продукт на основе TLS, несущий IP внутри себя, и портал приложений, обращённый к браузеру, — это выбор механизма, и у каждого свои переговоры, наборы шифров и режимы отказа. Ни один не подразумевает топологию, и топология не выбирает механизм.
Поместите две оси в одну таблицу, и путаница станет видимой, потому что каждую ячейку сетки можно заполнить. Чего таблица не может — сказать, какую комбинацию поставил ваш поставщик, поскольку названия продуктов сводят обе оси в одну маркетинговую фразу.
Откуда берётся категориальная ошибка
Поставщики годами продавали «SSL VPN» как противоположность «IPsec VPN», из-за чего сравнение механизмов выглядело как выбор топологии. Сама фраза плохо устарела и по своим собственным меркам, ведь современные проекты используют поддерживаемые версии TLS, а имя SSL сохраняется в основном как категория продукта.
| Axis | Question it settles | What it cannot tell you |
|---|---|---|
| Topology | Whether users join a gateway or two networks join each other | Which protocol carries the traffic, or how peers prove identity |
| Mechanism | Which protocol suite builds the tunnel and negotiates keys | Whether the endpoints are people, devices or routers |
| Access surface | Whether the client sees a routed network or a set of published applications | Which topology or mechanism is underneath the portal |
| Authentication | What proof each side presents, and to whom | Whether the traffic is later authorized per resource |
Из того же сведения следуют два связанных мифа. Первый — будто IPsec означает «сайт-сайт»; IKEv2 проектировался и для отношений клиент–шлюз, так что отдельный ноутбук может подключаться по IPsec. Второй — будто продукт на основе TLS означает только удалённый доступ; OpenVPN регулярно используется для переноса трафика между двумя площадками, а его использование TLS сосредоточено на обмене управлением и аутентификацией, а не на сеансе браузера.
Полезная проверка для любого описания: если замена одного слова меняет и конечные точки, и протокол, предложение смешивает оси. «SSL VPN против сайт-сайт» эту проверку не проходит, потому что первый термин называет семейство механизмов, а второй — топологию.
Опишите развёртывание так, чтобы его можно было сравнить
Напишите четыре поля и заполните их: конечные точки, механизм, аутентификация и поверхность доступа. Филиальное соединение можно прочитать как пару шлюзов IKEv2 между двумя именованными префиксами с аутентификацией по сертификату и без портала на уровне пользователя. Службу удалённого доступа можно прочитать как клиент на основе TLS, который выдаёт адреса каждому пользователю, требует второй фактор при входе и публикует только внутреннюю зону DNS.
Эти предложения сравнимы так, как названия продуктов — нет. Два проекта удалённого доступа можно измерить по одному и тому же пользовательскому сценарию и одному и тому же пути отзыва, а два проекта между площадками — по одному списку префиксов, политике трафика и требованиям к отказам. Ярлыки организуют сравнение; они его не заменяют.
У терминологии есть и опубликованная опора. Документ IETF по терминологии VPN отделяет несколько моделей обслуживания, включая удалённый доступ и «сайт-сайт», от механизмов, которыми они строятся, и это именно то различие, которое постоянно теряется.
Читайте согласованный протокол, а не название продукта
Ярлык на коробке не устанавливает, о чём договорился работающий туннель. Спросите партнёра напрямую, на стороне TLS, и прочитайте версию протокола и шифр, которые выдало рукопожатие, вместо версии из брошюры.
openssl s_client -connect vpn.example.net:443 -tls1_3 -brief
Для шлюза IPsec эквивалентное наблюдение берётся из собственного вывода состояния реализации, который сообщает об используемых предложениях IKE и ESP. Так или иначе, суть одна: ось механизма нужно читать из живой сессии, потому что клиент и шлюз могут договориться до чего-то более старого, чем ожидал любой из администраторов.
ipsec statusall | grep -E "IKE|ESP"
После этого остаются вопросы, на которые не отвечает ни один ярлык. Какие версии протокола ещё принимаются, как проверяется идентичность шлюза, какой набор алгоритмов разрешён, кто авторизует данного пользователя для данного ресурса и что отзывает доступ при потере устройства. Схема топологии и название механизма — начало этого списка, а не его замена.
Так что сохраните два ярлыка, но используйте их по назначению: короткий способ сказать, какие конечные точки соединяются и как строится туннель. В тот момент, когда один используется, чтобы исключить другой, описание перестаёт что-либо описывать.