Почему общий 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 приложения. Хост, который опирается на все три, в порядке. Хост, который опирается на первую и предполагает, что две другие пришли вместе с ней, — это тот, кто в итоге отдаёт неверное содержимое.