VPN-туннель: как он устроен внутри

Слово «туннель» в описаниях VPN выглядит как метафора для рекламы, но это довольно точное техническое название. Внутри действительно образуется отдельный канал: ваши пакеты едут не напрямую к сайту, а сначала внутрь другого пакета — до VPN-сервера, и только оттуда дальше.

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

Что называют туннелем

Туннель — приём, при котором пакет целиком помещается внутрь другого пакета, как письмо в конверт. Исходный пакет не меняется, не читается по пути и не обрабатывается промежуточным оборудованием: для сети он вообще не пакет, а полезная нагрузка внешнего пакета, то есть просто содержимое.

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

Что происходит с одним пакетом

Проследим путь запроса к сайту с момента, когда браузер отдал его системе.

Исходный пакет попадает в виртуальный интерфейс. В нём уже есть заголовок IP с внутренним адресом, выданным VPN-сервером, и заголовок TCP или UDP с номерами портов. Это законченный пакет — просто отправлять его в сеть как есть некуда.
Пакет шифруется целиком. Шифруется не только содержимое, но и внутренние заголовки: адрес получателя и номер порта тоже становятся нечитаемыми снаружи. Это ключевое отличие туннеля от шифрования отдельного соединения.
Добавляется служебная обвязка протокола. Счётчик пакета для защиты от повторной отправки, идентификатор сессии и метка проверки целостности — короткое значение, по которому получатель убедится, что пакет не подменили по дороге.
Сверху надеваются внешние заголовки. Новый заголовок IP с вашим настоящим адресом и адресом VPN-сервера плюс заголовок UDP или TCP с портом сервиса. Только эта часть остаётся открытой и видна сети.
Сервер разворачивает конструкцию. Проверяет метку целостности, отбрасывает пакет при несовпадении, расшифровывает содержимое, достаёт исходный пакет и отправляет его дальше уже от своего адреса. Ответ проходит тот же путь в обратном порядке.

Вся суть схемы — во втором и четвёртом шагах. Наружу видны только внешние заголовки: кто и с каким сервером обменивается данными. Всё, что внутри, — единый зашифрованный блок без различимой структуры.

Откуда берётся overhead

Обвязка занимает место, и место это отнимается у полезных данных. Складывается overhead из трёх частей: внешние заголовки доставки, служебные поля протокола и метка целостности. Для WireGuard поверх IPv4 это около шестидесяти байт, поверх IPv6 — примерно восемьдесят; у OpenVPN и IPsec цифры свои и зависят от режима работы.

На скорость это влияет предсказуемо и умеренно: при типичном размере пакета в полтора килобайта шестьдесят байт — примерно четыре процента канала, отданных за шифрование и адресацию. Гораздо интереснее второй эффект, из-за которого overhead обычно и замечают.

Почему из-за этого ломается MTU

У каждого участка сети есть максимальный размер пакета, который проходит целиком, — MTU. В обычной сети это 1500 байт. Если виртуальный интерфейс продолжает считать, что и внутри туннеля доступны те же 1500, то после упаковки пакет становится больше допустимого и по маршруту уже не проходит.

Дальше срабатывает неприятная комбинация. Современный TCP-трафик отправляется с запретом фрагментации, поэтому слишком большой пакет не разрезают, а отбрасывают, отправив назад служебное ICMP-сообщение. Эти сообщения часто теряются по пути, отправитель ничего не узнаёт и продолжает посылать пакеты того же размера. Мелкие запросы при этом проходят, крупные — нет, и картина получается характерная: пинг идёт, страница начинает открываться и обрывается на середине. Полный разбор с подбором значения — в материале про MTU и VPN.

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

Handshake: как стороны договариваются о ключах

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

Работает это на асимметричной криптографии. Каждая сторона генерирует пару значений: закрытое остаётся у неё, открытое отправляется собеседнику. Дальше каждый вычисляет общий секрет из своего закрытого значения и чужого открытого — и получает один и тот же результат, хотя сам секрет по сети не проходил ни разу. Наблюдатель видит только открытые части, из которых вывести результат за разумное время нельзя.

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

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

После рукопожатия начинается симметричное шифрование: оно на порядки быстрее асимметричного, поэтому весь поток данных идёт уже на согласованных ключах. Чем именно шифруют содержимое — в разборе шифрования AES-256.

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

HTTPS тоже шифрует, и вопрос «зачем тогда туннель» совершенно законный. Разница в уровне, на котором это происходит, и в том, что остаётся снаружи.

Область действия. HTTPS защищает одно соединение одного приложения. Туннель поднимается на уровне системы и забирает весь трафик устройства.
Что видно снаружи. При HTTPS открыт IP-адрес сайта и, как правило, имя домена в поле SNI при установке соединения. В туннеле оба этих признака оказываются внутри зашифрованной части, и наблюдателю остаётся только адрес VPN-сервера.
Что защищается. HTTPS отвечает за содержимое сессии между браузером и сайтом. Туннель отвечает за транспорт до сервера и не имеет отношения к тому, что происходит после него.
Кто вторая сторона. В HTTPS это сам сайт. В туннеле — VPN-сервер, а до сайта трафик всё равно доедет обычным способом.

Отсюда важный вывод: они не заменяют друг друга, а складываются. Внутри туннеля ваш HTTPS остаётся HTTPS — просто снаружи не видно, к какому сайту он ведёт. Что именно открыто в обычном HTTPS-соединении, подробно разобрано в статье про SNI.

Шифрование делает содержимое нечитаемым. Туннель делает нечитаемым ещё и адрес получателя — но взамен создаёт один хорошо заметный маршрут, по которому идёт всё сразу.

Почему туннель видно, а содержимое — нет

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

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

А внутри для наблюдателя нет ничего. Имена сайтов, адреса получателей, содержимое запросов, DNS-запросы, если они идут через туннель, — всё это часть зашифрованной полезной нагрузки. Разница между «видно, что вы подключены к VPN» и «видно, что вы делаете» здесь принципиальная, и путают её постоянно.

Чего VPN здесь не делает

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

Не скрывает сам факт подключения. Внешние заголовки открыты всегда, и по ним видно, что трафик постоянным потоком идёт к одному адресу.
Не защищает то, что происходит после сервера. От VPN-сервера до сайта пакет едет обычным путём; если соединение с сайтом не защищено HTTPS, туннель этого не исправит.
Не влияет на то, как вас узнают сайты. Cookie, вход в аккаунт и отпечаток браузера живут выше уровня туннеля и работают одинаково.
Не проверяет содержимое. Шифрование не отличает полезный файл от вредоносного, а поддельную страницу от настоящей.
Не ускоряет интернет. Маршрут через сервер почти всегда длиннее прямого, плюс несколько процентов канала уходят на обвязку.
Не отменяет ошибок настройки. Запрос, ушедший мимо виртуального интерфейса — DNS или IPv6, — едет открытым, и шифрование внутри туннеля к нему не относится.

И отдельно: устройство туннеля ничего не говорит о том, кто держит сервер на другом конце. Шифрование гарантирует, что содержимое не прочитают по дороге, но на выходе трафик всё равно расшифровывается — и вопрос доверия к владельцу сервера остаётся открытым.

Частые вопросы

Туннель и шифрование — это одно и то же?

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

Почему скорость падает, хотя канал не загружен?

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

Что происходит с туннелем при переходе с Wi-Fi на мобильную сеть?

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

Вывод

VPN-туннель устроен проще, чем кажется по маркетинговым описаниям: исходный пакет шифруется целиком, обрастает служебной обвязкой и уезжает внутри нового пакета до сервера, где всё разворачивается обратно. Из этой конструкции напрямую вытекают и её свойства — несколько процентов overhead, требование уменьшить MTU, невидимость содержимого и полная видимость самого факта подключения. Понимать механику полезно не ради теории: именно она объясняет, почему сайты грузятся наполовину при неверных настройках и почему «шифрует весь трафик» и «делает вас невидимым» — совсем не одно и то же.