Зашифрован ли HTTP поверх ZeroTier? Проверьте, где заканчивается оверлей

Пройдите эти проверки по порядку и остановитесь на первой неудачной, потому что каждый ответ меняет смысл следующего шага. Настоящий вопрос узок: ходит ли обычный HTTP в сети ZeroTier по интернету в открытом виде? Между двумя пирами ZeroTier обычно нет, поскольку оверлей шифрует этот переход. Но это утверждение о двух конечных точках, а не о каждом сегменте, который проходит запрос. Маршрутизатор, мост или обратный прокси сдвигает конечную точку, и по другую его сторону открытый текст начинается снова.

Проверка 1: найдите адрес, по которому обращается браузер

Сравните URL с тем, что машина действительно имеет. ip -brief addr show показывает интерфейс zt и адрес оверлея, назначенный контроллером сети; если URL использует этот адрес, сокет браузера уходит в оверлей.

Когда имя вместо этого разрешается в адрес LAN, оверлей может быть вовсе не задействован, что бы ни подсказывал индикатор состояния клиента. ip route get 10.147.20.5 печатает интерфейс и исходный адрес, который выбрало бы ядро, поэтому интерфейс zt там означает, что пакет попадает в оверлей, а имя вашей физической сетевой карты означает, что нет. Имена добавляют ещё один слой: запись, указывающая на адрес оверлея, ведёт себя иначе, чем указывающая на адрес LAN, а суффикс поиска или запись в файле hosts может тихо решить, какую вы получите.

Проверка 2: убедитесь, что оба конца — пиры, а не расшифровывающий ретранслятор

ZeroTier шифрует между пирами, а там, где нет прямого пути, пакеты передаются через корень, который пересылает их всё ещё зашифрованными. zerotier-cli peers помечает путь каждого пира как DIRECT или RELAY вместе с цифрой задержки. Переданный через ретранслятор путь стоит лишних круговых обходов, а не конфиденциальности.

Ответ меняет участник, который на самом деле не является конечной точкой. Когда противоположная сторона — участник ZeroTier, маршрутизирующий или мостящий в физическую LAN, оверлей заканчивается на этом участнике, а следующий переход — обычный Ethernet.

Проверка 3: посмотрите, где запрос становится читаемым

На хосте, который, по вашему мнению, отдаёт страницу, перехватите интерфейс оверлея при перезагрузке: sudo tcpdump -i ztxxxxxxx -A -c 5 'tcp port 80'. Читаемая строка запроса в этом выводе доказывает, что трафик пришёл на этот хост расшифрованным, и это та граница, которую вы ищете.

Затем перехватите на интерфейсе, обращённом к остальной LAN. Если тот же запрос появится там в открытом виде, он покинул оверлей до того, как дошёл до приложения, и любое устройство в этом сегменте может его прочитать. Если со стороны LAN ничего не появляется, а страница всё равно загружается, приложение завершает соединение на самом хосте ZeroTier.

Перехват loopback тоже важен, когда впереди стоит обратный прокси, поскольку прокси, принимающий HTTPS и пересылающий HTTP, переносит границу на собственный бэкенд.

Проверка 4: учтите каждый переход за маршрутизатором или мостом

Участник, настроенный маршрутизировать между оверлеем и LAN, — обычная схема и место, где большинство этих допущений ломается. Оверлей защищает участок от браузера до маршрутизатора и ничего после него. Мост рассказывает ту же историю другим механизмом: оверлей и физический сегмент становятся одним широковещательным доменом, поэтому запрос с ноутбука, подключённого через мост, идёт по обычному Ethernet, даже если этот ноутбук находится в сети ZeroTier.

Проследите это, а не предполагайте. traceroute от клиента до адреса службы вместе с таблицей маршрутизации на шлюзовом участнике показывает, является ли последний переход zt или eth.

ZeroTier также предлагает режим доверенного пути, который может отказаться от защиты транспорта на назначенных локальных путях ради производительности. Сеть, использующая его, не наследует обычное допущение о зашифрованном пути, поэтому прочитайте конфигурацию сети, прежде чем ссылаться на него. Документация протокола описывает и шифрование между пирами, и это исключение.

Проверка 5: решите, что приложению всё ещё нужно сделать

Членство в оверлее аутентифицирует устройство в сети и ничего не говорит о том, является ли служба на другом конце той, до которой вы хотели добраться. HTTPS отвечает на другой вопрос, привязывая имя хоста к ключу, поэтому две защиты перекрываются, не заменяя друг друга. Авторизованный пир всё ещё может оказаться не той службой, а скомпрометированная конечная точка читает запрос и до шифрования, и после расшифровки. Ни один из механизмов не проверяет, что записывает приложение.

Для всего с повторно используемой сессией или паролем завершайте TLS на приложении или на прокси, который вы контролируете, и оставляйте проверку сертификата включённой. Там, где устаревшая служба должна остаться на обычном HTTP, запишите точный путь от хоста к хосту, который ей разрешён, кто может до неё добраться и какой сегмент остаётся незащищённым; именно эта заметка нужна будущему проверяющему.

"VPN подключён" не является оценкой ничего из этого. Честная версия называет обе конечные точки, путь между ними и первый непокрытый переход.

Держите вывод перехвата и список пиров рядом с документацией службы, чтобы тот, кто меняет маршрут или добавляет мост, видел, какое допущение он собирается нарушить.