Что шифрует туннель и что оставляет читаемым

Ваш туннель поднят, на одной вкладке зелёный замок, а обычная HTTP-страница на другой вкладке всё ещё предупреждает, что соединение не защищено. Это сочетание сбивает людей с толку, потому что две защиты покрывают разные расстояния. VPN защищает трафик между своими конечными точками, а за выходом трафик снова становится обычным. HTTPS защищает одно соединение вплоть до сайта. Если поставить эти два факта рядом, объяснится большинство вопросов о том, что VPN на самом деле скрывает.

Что туннель действительно покрывает

Между клиентом и партнёром VPN наблюдатель видит зашифрованные байты, а не читаемый запрос. Это охватывает участок, который проходит туннель, и обычно это та часть, которую вы не контролируете. Это не доходит до звена между выходом VPN и сайтом, потому что туннель закончился на выходе. Байты снова становятся читаемыми с момента, когда туннель заканчивается. Ничто в этом не является ошибкой настройки.

Выход — это машина, которая расшифровывает и пересылает, и именно для этого нужен VPN. Всё, что она пересылает, видно ей в том виде, в каком было получено, поэтому обычный HTTP-запрос остаётся открытым текстом от выхода и далее.

Читайте это как свойство, а не как недостаток. Шифрование ограничено путём, а путь заканчивается там, где начинается служба.

Ключи, nonce и целостность простыми словами

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

Ключи берутся из этого обмена, а не из пароля, введённого при входе. Пароль удостоверяет личность, а затем протокол устанавливает материал сеанса. Эфемерный обмен ключами даёт прямую секретность, поэтому записанный сеанс остаётся нечитаемым, даже если долговременный ключ позже утечёт.

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

Где заканчивается туннель

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

HTTPS продолжается за этой точкой, поэтому сайт может быть безопасным во враждебной сети даже без VPN. Две защиты перекрываются на первом участке, и только одна из них продолжается после выхода.

Именно поэтому ослабление проверки сертификата, чтобы соединение заработало, не является проверкой туннеля. Оно отключает другую защиту и оставляет вас с меньшим, чем было в начале.

Почему анонимность — это другой продукт

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

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

Выбирайте провайдера по его политике журналирования и юрисдикции, если это требование, а затем читайте саму политику. Маркетинговые страницы редко отвечают на этот вопрос так, чтобы кто-то мог проверить.

Проверяйте туннель и сайт отдельно

Сначала проверьте туннель, чтобы знать, какую защиту вы тестируете. Затем проверьте собственный транспорт сайта и сравните два результата, а не предполагайте, что одно подразумевает другое. Туннель, несущий обычный HTTP, и сайт, отдающий HTTPS, оба делают именно то, для чего настроены.

Выполняйте проверки на хосте, который вам разрешено тестировать, и читайте вывод, а не сводку.

wg show
ip -brief addr show tun0
curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' https://example.com

Когда туннель поднят и сайт работает по HTTPS, у вас две защиты на первом участке и одна на втором. Когда сайт работает по обычному HTTP, второй участок читаем для всех, кто в нём находится, включая выход, который переслал запрос. Знание того, какой из двух не хватает, — это весь диагноз, и для него нужны две команды, а не новый клиент.