Как работает VPN?

Как работает VPN? Твоё устройство строит зашифрованный туннель к выбранному серверу, отправляет каждый пакет через него, и сервер форвардит трафик к реальному назначению со своего IP. Тот, кто наблюдает за сетью между тобой и VPN-сервером, видит только зашифрованный шум, идущий на один адрес. Тот, кто наблюдает за VPN-сервером, видит трафик с IP сервера, не с твоего.

Это версия за 30 секунд. Остальной пост распаковывает каждый шаг с реальными деталями протоколов, потому что «зашифрованный туннель» — фраза, скрывающая много интересной механики. Разберём, что реально происходит во время handshake VPN, что значит инкапсуляция на уровне пакетов, почему DNS должен идти через туннель отдельно, как работает маскировка IP (это не магия, это NAT), и чем три основных протокола различаются.

Написано для тех, кто хочет понять систему без диплома по сетям.

Версия за 30 секунд

Ставишь VPN-клиент и жмёшь Connect. За кулисами:

Клиент и сервер делают handshake. Доказывают друг другу, кто они, и согласуют общие ключи шифрования. Один-два round trip.
Твоя ОС маршрутизирует трафик в туннель. Клиент говорит ОС: «отправляй всё через этот виртуальный сетевой адаптер». Туннель теперь дефолтный маршрут.
Каждый пакет шифруется, обёртывается и отправляется. Исходный пакет (предназначенный, скажем, Wikipedia) шифруется и кладётся внутрь нового внешнего пакета, адресованного VPN-серверу. С точки зрения сети ты разговариваешь только с VPN-сервером.
Сервер разворачивает и форвардит. Расшифровывает внутренний пакет, видит Wikipedia как назначение, отправляет его дальше, подставляя свой IP как источник. Wikipedia отвечает серверу, который разворачивает процесс назад.
DNS идёт через тот же туннель. Лукап wikipedia.org идёт через зашифрованный туннель и резолвится на DNS VPN-провайдера, не провайдера твоего интернета.

Это весь пайплайн. Остальное — вариации в реализации каждого шага.

Шаг 1: handshake и обмен ключами

Шифрование работает, только если обе стороны согласовали ключ. Handshake устанавливает этот ключ через сеть, где каждый байт могут наблюдать.

Современные VPN-протоколы используют Diffie-Hellman или его эллиптический вариант X25519. Две стороны генерируют пары публичный-приватный ключ, обмениваются публичными половинами и независимо вычисляют общий секрет, причём секрет никогда не пересекает провод. Подслушивающий, захвативший каждый байт, не может его вывести.

Каждый протокол реализует это по-своему:

WireGuard. Один round trip. Клиент шлёт Noise-инициацию с эфемерным публичным ключом и идентичностью (зашифрованной статическим публичным ключом сервера). Сервер отвечает своим эфемерным публичным ключом. Обе стороны выводят симметричные сессионные ключи через HKDF и начинают слать данные. Время handshake на здоровой сети: 100 мс или меньше.

OpenVPN. Полный TLS 1.2 или TLS 1.3 handshake — тот же обмен, что делает браузер при подключении к HTTPS-сайту. ClientHello, ServerHello, обмен сертификатами, обмен ключами, finished. Больше round trips, больше байт, больше CPU. Время handshake: 500 мс — секунда с лишним на медленных сетях.

VLESS Reality. TLS 1.3 handshake к настоящему легитимному сайту (SNI-цель). Протокол Reality криптографически связывает соединение с TLS-сертификатом этой цели, при этом маршрутизируя трафик к другому VPN-серверу. Для сетевого наблюдателя handshake неотличим от того, как кто-то заходит на SNI-цель. VPN-аутентификация происходит внутри TLS-сессии через UUID.

После handshake у обеих сторон симметричные сессионные ключи. Симметричное шифрование быстрое; асимметричное (с публичным ключом) медленное. Handshake устанавливает дешёвую симметричную сессию эффективно. HTTPS использует тот же паттерн по той же причине.

Шаг 2: инкапсуляция, не физический туннелинг

Слово «туннель» вызывает в воображении физическое разделение, частную дорогу параллельно публичному интернету. Реальность интереснее. Туннель VPN — это просто инкапсуляция: один пакет внутри другого пакета.

Представь обычный IP-пакет к Wikipedia. У него заголовок (источник: твоё устройство, назначение: IP Wikipedia) и полезная нагрузка (HTTP-запрос). Когда туннель поднят, клиент берёт весь пакет, шифрует его и засовывает в новый внешний пакет, адресованный VPN-серверу. Исходный пакет теперь спрятан внутри новой обёртки.

Роутеры между тобой и VPN-сервером видят только внешнюю обёртку. Маршрутизируют по внешнему заголовку, который говорит «отправь это VPN-серверу». Когда пакет приходит, сервер расшифровывает нагрузку, находит исходный пакет внутри и форвардит его дальше.

Этот трюк (один IP-пакет оборачивает другой) — механизм за каждым «туннельным» протоколом в интернете. GRE, IPsec, WireGuard, OpenVPN: вариации одной темы. Инкапсуляция происходит на виртуальном сетевом адаптере, который ставит VPN-клиент (Wintun на Windows, TUN на Linux, utun на macOS). ОС видит обычный сетевой интерфейс; VPN-клиент перехватывает каждый пакет, маршрутизированный туда, шифрует и отправляет результат через настоящую сеть.

Шаг 3: шифрование в передаче

Как только handshake даёт сессионные ключи, протокол использует их для шифрования каждого пакета трафика. Выбор шифров важен для безопасности и производительности.

ChaCha20-Poly1305. Поточный шифр со встроенной аутентификацией. Быстр на устройствах без аппаратного ускорения AES (старые телефоны, low-end роутеры). WireGuard использует только его. OpenVPN поддерживает. ChaCha20 — современный дефолт для протоколов, спроектированных за последнее десятилетие.

AES-256-GCM. Аналог в блочных шифрах. Инструкции AES-NI на каждом CPU Intel и AMD с 2010-го делают это самым быстрым вариантом на десктопном железе. Современный дефолт OpenVPN. WireGuard его не использует (авторы намеренно выбрали ChaCha20, чтобы не зависеть от AES-NI для embedded).

AES-128-GCM. То же семейство, меньший ключ. Чуть быстрее, чуть менее параноично. Современные протоколы по умолчанию используют 256.

Части «GCM» и «Poly1305» важны: это теги аутентификации. Шифрование само по себе говорит, что атакующий не прочтёт твой трафик; аутентификация — что не модифицирует его незаметно. VPN, который шифрует, но не аутентифицирует, сломан. Каждый современный протокол использует authenticated encryption (AEAD).

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

Шаг 4: DNS-резолюция через туннель

DNS — система, превращающая wikipedia.org в IP-адрес. По умолчанию ОС шлёт DNS-запросы на резолвер, который выдал DHCP — обычно это провайдер. Это происходит до любого веб-трафика.

Без обработки DNS VPN сильно течёт. Поднимаешь туннель, браузер просит ОС найти bank.com, ОС шлёт лукап на DNS провайдера (вне туннеля), и провайдер получает список каждого посещённого домена, несмотря на то, что зашифрованный туннель честно работает для самого трафика.

Корректно реализованный VPN-клиент маршрутизирует DNS через туннель. Несколько механизмов:

Заменить системный DNS-резолвер. Клиент ставит DNS-сервер в сетевой конфигурации ОС на резолвер VPN-провайдера, доступный только через туннель. Стандартный подход.

Блокировка DNS-ликов через файрвол. На Windows VPN-клиент использует WFP-фильтры, блокирующие DNS-запросы на любом интерфейсе, кроме туннеля. Belt-and-suspenders: даже если что-то попытается отправить DNS-запрос не туда, файрвол его дропнет.

Отключить smart-multi-homed name resolution. Windows по умолчанию шлёт DNS-запросы на несколько сетевых интерфейсов параллельно и использует ответ, пришедший первым. Эта фича Windows, SMHNR, утекает DNS на исходный резолвер провайдера каждый раз, даже с активным VPN. Корректный VPN-клиент отключает SMHNR через NRPT или записи реестра.

Блокировать IPv6, если туннель IPv4-only. Если сеть поддерживает IPv6, а VPN не туннелирует — IPv6 DNS-запросы пропускают туннель полностью. Либо туннелируй IPv6, либо блокируй.

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

Шаг 5: маскировка IP через NAT

Когда VPN-сервер форвардит внутренний пакет к Wikipedia, он должен решить: как Wikipedia узнает, куда слать ответ?

Ответ — Network Address Translation (NAT). VPN-сервер переписывает source IP исходящего пакета с твоего туннельного IP на свой публичный IP и записывает mapping в NAT-таблицу. Когда Wikipedia отвечает, сервер ищет mapping, переписывает destination обратно на твой туннельный IP, шифрует пакет и отправляет обратно через туннель. Тот же NAT, что у домашнего роутера, только в масштабе.

С точки зрения Wikipedia, источник твоего запроса — публичный IP VPN-сервера. Wikipedia не может вывести твой домашний IP из этого соединения. Они могут понять, что используешь VPN, если кросс-чекают IP против списков известных VPN-выходов (большинство крупных сайтов делает это для антифрода), но не могут идентифицировать тебя конкретно.

Это объясняет, почему «общие IP» — плюс приватности и минус юзабилити. Если сотни людей выходят через один IP, трафик к данному сайту не может быть атрибутирован никому из них. Минус: общие IP чаще флагуются или ограничиваются по rate сайтами, которые им не доверяют (некоторые банки, captcha, стриминги).

Шаг 6: трюк маршрутизации ОС

Как VPN-клиент убеждает ОС отправлять трафик в туннель? Не перехватом отдельных сокетов. Стандартный подход — установить виртуальный сетевой адаптер и изменить таблицу маршрутизации, чтобы он стал дефолтным маршрутом.

Клиент добавляет:

Новый дефолтный маршрут через виртуальный адаптер (часто как split-маршруты 0.0.0.0/1 и 128.0.0.0/1, перекрывающие существующий дефолт без удаления).
Конкретный маршрут к IP VPN-сервера через исходный физический адаптер, чтобы зашифрованные внешние пакеты могли реально покинуть устройство.
DNS-сервер на туннельный резолвер.

Каждый исходящий пакет (кроме адресованных VPN-серверу) теперь маршрутизируется на виртуальный адаптер. VPN-клиент их подхватывает, шифрует, инкапсулирует и шлёт результат через физический адаптер. Kill switch живёт на этом же слое: если туннель падает, клиент либо держит маршруты указывающими на несуществующий gateway (трафик уходит в чёрную дыру), либо ставит файрвольные правила, блокирующие трафик до реконнекта.

Чем протоколы различаются в проводке

Общий скелет покрыли. Каждый протокол заполняет детали по-своему.

WireGuard. Только UDP. Фиксированный размер handshake (148 байт инициация, 92 байта ответ). Только ChaCha20-Poly1305. Нормально роумит между сетями, потому что состояние сессии привязано к статическим идентичностям, не к паре IP/port. Userspace-реализации существуют (boringtun, который использует Fexyn), но и kernel-реализации тоже. Время подключения — самое низкое из трёх: меньше секунды, часто меньше 500 мс на тёплом пути.

OpenVPN. UDP или TCP. Контрольный канал на TLS, отдельный канал данных. Конфигурируемый шифр (современный: AES-256-GCM или ChaCha20-Poly1305). Только userspace, более крупная кодовая база, больше настроек. Медленный handshake, больший оверхед на пакет. Ветеран совместимости: работает на сетях, где WireGuard не работает, особенно в TCP-режиме, где соединение выглядит как обычный зашифрованный TCP-поток.

VLESS Reality. Только TCP. Весь смысл — выглядеть для сетевого наблюдателя как обычный HTTPS. Handshake — настоящий TLS 1.3 handshake к настоящему легитимному сайту (настроенному как SNI-цель и на клиенте, и на сервере). Внутри TLS-сессии VLESS несёт идентичность (UUID) и трафик. Vision flow (xtls-rprx-vision), который используем мы, добавляет легковесный внутренний фрейминг для VPN-трафика. Медленнее WireGuard по сырой пропускной, но выживает в средах, где WireGuard и OpenVPN заблокированы наглухо.

Современный клиент выбирает по сети. Быстрые открытые сети: WireGuard. Сети, блокирующие WireGuard, но разрешающие обычный TLS: VLESS Reality. Сети, блокирующие оба, но разрешающие OpenVPN-форму трафика: OpenVPN как последний fallback. Движок ротации Fexyn делает это автоматически.

Что видит провайдер с VPN включённым vs выключенным

VPN выключен. Провайдер видит IP каждого сервера, к которому подключаешься, домены, которые ищешь через DNS, и сколько данных течёт когда. Не может прочитать содержимое HTTPS, но может прочитать SNI (домен в TLS-handshakes) — та же доменная видимость с другого угла.

VPN включён, хорошо реализованный клиент. Провайдер видит один IP (VPN-сервер), зашифрованные байты, текущие к нему, и паттерны таймингов. DNS-запросы идут через туннель, провайдер их не читает. SNI больше не виден для реального трафика — единственный TLS-handshake, который видит провайдер, это к VPN-серверу (или к SNI-цели с Reality, обычно популярному сайту, ничего не раскрывающему о твоём назначении). Провайдер обычно может зафиксировать, что используешь VPN, но не какие сайты через него посещаешь.

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

Оверхед производительности

VPN добавляет два расхода: работу шифрования на CPU и дополнительный хоп на пути трафика.

CPU. Современные AES и ChaCha20 двигаются на нескольких гигабитах в секунду на одно ядро. Для типичного домашнего интернета (меньше 1 Gbps) оверхед CPU невидимый.

Задержка. Дополнительный хоп добавляет задержку пропорционально географическому расстоянию между тобой, VPN-сервером и назначением. Близкий выход добавляет 5–20 мс; трансконтинентальный — 100 мс и больше. Браузинг и стриминг это нормально поглощают; соревновательные игры — нет.

Пропускная. WireGuard добавляет около 60 байт на пакет (внешние IP/UDP-заголовки плюс тег аутентификации), примерно 4% оверхеда фрейминга на MTU 1500. Оверхед OpenVPN ближе к 10%. Реальное падение пропускной обычно больше, чем посчитанное на пакет, потому что VPN-сервер может стать узким местом, если недоразмерен под количество пользователей. По нашим тестам WireGuard стоит 5–10% общей пропускной на здоровой сети; OpenVPN — 15–25%. VLESS Reality между ними с большим разбросом из-за TLS-фрейминга.

Итог

VPN работает, шифруя и инкапсулируя трафик, отправляя его через выбранный сервер и форвардя дальше с NAT. Handshake устанавливает сессионные ключи. Инкапсуляция делает так, что роутеры видят только внешний пакет. DNS, kill switch и изменения таблицы маршрутизации ловят краевые случаи, которые иначе утекли бы реальной идентичностью сети.

Механизм понятен и не магичен. Польза для приватности зависит от того, через кого маршрутизируешь и что они делают с тем, что видят. Выбери протокол под условия сети, провайдера под требования к доверию и клиент, корректно обрабатывающий векторы лика (DNS, IPv6, SMHNR, kill switch).

FAQ

Зашифрованные, инкапсулированные IP-пакеты. Исходный пакет (с реальным источником и назначением) шифруется и кладётся внутрь нового внешнего пакета, адресованного VPN-серверу. Для наблюдателя сети внешний пакет — всё, что видно.

Handshake использует криптографию с публичным ключом (X25519 в WireGuard, RSA или ECDHE в TLS для OpenVPN и Reality), чтобы установить симметричные сессионные ключи без передачи их по проводу. Когда у обеих сторон есть сессионные ключи, каждый пакет шифруется быстрым симметричным шифром (ChaCha20-Poly1305 или AES-256-GCM) со встроенной аутентификацией.

DNS-лукапы происходят до веб-трафика и могут утекать независимо от туннеля. По умолчанию ОС шлёт DNS на резолвер, выданный DHCP, обычно — провайдер. VPN-клиент должен активно перенаправить DNS в туннель и блокировать пути утечки (Windows SMHNR, IPv6 fallback, браузерный DoH в обход OS DNS).

TUN — виртуальный layer-3 (IP) интерфейс; TAP — виртуальный layer-2 (Ethernet). VPN почти всегда используют TUN, потому что им нужно перевозить только IP-пакеты. TAP — для случаев с эмуляцией Ethernet, например мостинг локальных сетей.

Да, часто. У пакетов WireGuard узнаваемая форма; OpenVPN над UDP имеет характерный заголовок. Даже зашифрованный трафик имеет паттерны размера и тайминга, которые ловят инструменты фингерпринтинга. VLESS Reality наиболее устойчив, потому что мимикрирует под настоящий TLS к настоящему популярному сайту. «Зашифрованный» и «незаметный» — разные задачи.

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

Да, от оператора сети. Точка доступа Wi-Fi видит зашифрованный туннель к VPN-серверу. Не может прочитать трафик, увидеть посещаемые сайты или инжектить контент. HTTPS уже многое от этого защищает; VPN добавляет оборону по слоям и защищает метаданные вроде SNI.

Меньший handshake (один round trip против нескольких), меньший оверхед на пакет, более простая кодовая база, легче оптимизируемая, и осознанный одно-шифровый дизайн без оверхеда переговоров. WireGuard спроектирован в 2015-м с уроками старых протоколов в виду.

В сети: нет. Видят зашифрованные байты к VPN-серверу, как видел бы провайдер. На устройстве: возможно. Если на рабочем устройстве корпоративное управляющее ПО (MDM, EDR), оно может читать трафик на уровне ОС до входа в VPN. Сетевая приватность реальна; приватность устройства зависит от устройства.