Собственный VPN-сервер против коммерческого провайдера: реальные границы приватности

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

Что VPN реально скрывает и что не скрывает​

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

Что скрывается от локального наблюдателя (провайдер, администратор сети, сосед по Wi-Fi):

• Содержимое запросов и ответов.
  
• Конкретные посещаемые ресурсы (если сайт использует HTTPS, содержимое и так зашифровано, но DNS-запросы и SNI могут быть видны без VPN).
  
• Метаданные сессий: объём, тайминги, направление.
  

Что не скрывается от точки выхода (VPN-сервер):

• Расшифрованный трафик полностью доступен серверу. Это фундаментальное свойство любого VPN: сервер должен расшифровать пакет, чтобы переслать его дальше.
  
• DNS-запросы, если они идут через туннель.
  
• IP-адрес клиента виден серверу как источник туннельного соединения.
  

Что не скрывается от конечного сайта:

• IP-адрес точки выхода (сервера провайдера или вашего собственного).
  
• HTTP-заголовки, cookies, TLS-фингерпринт браузера.
  

Ключевой вывод: VPN защищает канал, а не личность. Приватность зависит от того, кому вы доверяете точку выхода.

Коммерческий провайдер: модель доверия​

Коммерческий VPN-сервис — это третья сторона, которой вы передаёте расшифрованный трафик. Модель угроз здесь строится на нескольких вопросах:

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

Что логируется? Политика «no logs» — маркетинговая формулировка. На практике нужно смотреть, какие именно данные не пишутся: IP-адреса клиентов, временные метки подключений, объём трафика, DNS-запросы. Даже без логов содержимого, метаданные позволяют восстановить картину активности.

Что происходит при юридическом давлении? Известны случаи, когда провайдеры с политикой «no logs» передавали данные по решению суда — потому что логи всё-таки велись, или потому что инфраструктура позволяла начать логирование задним числом.

Преимущества коммерческого VPN:

• Множество точек выхода в разных странах.
  
• Разделение трафика: один и тот же провайдер обслуживает тысячи пользователей, что затрудняет корреляцию конкретного человека с конкретным действием.
  
• Не нужно администрировать инфраструктуру.
  
• IP-адреса серверов обычно не привязаны к конкретному пользователю.
  

Недостатки:

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

Собственный сервер: модель доверия​

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

Что даёт собственный сервер:

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

Что не даёт собственный сервер:

• Анонимность. Ваш сервер имеет фиксированный IP-адрес, привязанный к аккаунту хостинг-провайдера. Хостинг-провайдер знает, кто арендовал сервер, и может предоставить эти данные по запросу. Коммерческий VPN распределяет тысячи пользователей по одним и тем же IP, ваш сервер — это один IP, один пользователь.
  
• Маскировка. Трафик с вашего сервера легко коррелируется: один входящий туннель, один исходящий поток. У коммерческого провайдера на одном сервере сотни одновременных подключений.
  
• Защита от корреляции по времени и объёму. Если наблюдатель видит входящий трафик на ваш сервер и исходящий с него, он может сопоставить объёмы и тайминги.
  
• Отказоустойчивость. Один сервер — одна точка отказа. Коммерческий провайдер обычно предлагает переключение между серверами.
  

Критическая проблема: хостинг-провайдер. Арендуя VPS, вы передаёте метаданные хостеру: IP-адрес, время аренды, способ оплаты. Если хостер находится в юрисдикции с обязательным хранением данных, эти метаданные доступны по запросу. Это не отменяет преимуществ собственного сервера, но смещает точку доверия с VPN-провайдера на хостинг-провайдера.

Протокол: WireGuard как практический выбор​

Для собственного сервера WireGuard является наиболее практичным вариантом. Он встроен в ядро Linux, использует современную криптографию (Curve25519 для обмена ключами, ChaCha20-Poly1305 для шифрования, BLAKE2s для хеширования) и имеет минимальную кодовую базу, что упрощает аудит.

WireGuard работает как сетевой интерфейс (например, wg0), маршрутизирует пакеты на основе привязки публичных ключей к разрешённым IP-адресам (Cryptokey Routing) и обеспечивает perfect forward secrecy.

Минимальная конфигурация сервера:

[Interface]
PrivateKey = <приватный_ключ_сервера>
ListenPort = 51820

[Peer]
PublicKey = <публичный_ключ_клиента>
AllowedIPs = 10.192.122.3/32

Минимальная конфигурация клиента:

[Interface]
PrivateKey = <приватный_ключ_клиента>

[Peer]
PublicKey = <публичный_ключ_сервера>
Endpoint = <IP_сервера>:51820
AllowedIPs = 0.0.0.0/0

Параметр AllowedIPs = 0.0.0.0/0 на клиенте означает, что весь трафик направляется через туннель. На сервере AllowedIPs для каждого пира задаёт, с каких адресов этот пир может отправлять пакеты — это одновременно таблица маршрутизации и access control list.

Ограничение WireGuard в контексте приватности: протокол не скрывает факт использования VPN. Пакеты имеют характерный размер и структуру, что позволяет DPI-системам идентифицировать туннель. Если задача — скрыть сам факт использования VPN от провайдера, потребуется дополнительная обфускация (например, AmneziaWG или оборачивание в TLS).

Сравнение по конкретным сценариям​

Сценарий	Коммерческий VPN	Свой сервер
Защита от локального наблюдателя (кафе, отель)	Да	Да
Скрытие трафика от интернет-провайдера	Да	Да
Анонимность от посещаемых сайтов	Частично (общий IP)	Нет (уникальный IP)
Защита от запросов правоохранительных органов	Зависит от юрисдикции и политики	Зависит от юрисдикции хостинга
Контроль над логированием	Нет	Да
Устойчивость к корреляции трафика	Выше (много пользователей на IP)	Ниже (один пользователь)
Обход гео-блокировок	Да (выбор страны)	Да (выбор страны хостинга)

Типичные ошибки при настройке собственного сервера​

Утечка DNS. Если DNS-запросы идут мимо туннеля, провайдер видит, какие домены вы запрашиваете. Решение: настроить DNS внутри туннеля (например, указать DNS = 10.192.122.1 в конфигурации клиента) и убедиться, что системный резолвер не отправляет запросы напрямую.

Утечка IPv6. Если у клиента есть IPv6-адрес и туннель не покрывает IPv6-трафик, часть запросов уйдёт напрямую. Решение: либо настроить туннелирование IPv6, либо отключить его на клиенте.

Kill switch отсутствует. При обрыве туннеля трафик пойдёт напрямую. На Linux это решается через iptables или nftables: запретить исходящий трафик кроме интерфейса wg0 и адреса сервера.

## Пример: разрешить только трафик через wg0 и к серверу
iptables -A OUTPUT -o wg0 -j ACCEPT
iptables -A OUTPUT -d <IP_сервера> -j ACCEPT
iptables -A OUTPUT -j DROP

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

Логи на сервере. По умолчанию WireGuard не ведёт логов подключений, но системный журнал (journald, syslog) может фиксировать события интерфейса. Проверьте конфигурацию логирования и при необходимости ограничьте её.

Когда собственный сервер не решает задачу приватности​

Есть ситуации, где собственный сервер объективно хуже коммерческого:

• Нужна анонимность от целевого ресурса. Фиксированный IP, привязанный к вашему аккаунту хостинга, не обеспечивает анонимности. Коммерческий провайдер с общим IP-пулом даёт лучшую защиту от идентификации.
  
• Нужна защита от корреляции. Один пользователь на сервере — тривиальная задача для корреляционного анализа. Коммерческий провайдер с сотнями пользователей на сервере затрудняет выделение конкретного потока.
  
• Нужна защита от компрометации хостинга. Если хостинг-провайдер скомпрометирован или сотрудничает с органами, ваш сервер доступен для инспекции. У коммерческого провайдера инфраструктура распределена, и компрометация одного сервера не раскрывает всех пользователей.
  

Практический чек-лист перед развёртыванием​

• Определите модель угроз: от кого именно вы защищаетесь — локальный наблюдатель, интернет-провайдер, целевой ресурс, правоохранительные органы.
  
• Выберите юрисдикцию хостинга с учётом законодательства о хранении данных.
  
• Используйте WireGuard или другой протокол с современным шифрованием.
  
• Настройте DNS внутри туннеля.
  
• Отключите или туннелируйте IPv6.
  
• Настройте kill switch.
  
• Проверьте отсутствие утечек через специализированные сервисы (например, запрос к ifconfig.me или проверка DNS через dig/nslookup).
  
• Ограничьте логирование на сервере.
  
• Если нужна анонимность, а не только конфиденциальность канала, рассмотрите комбинацию: собственный сервер как входная точка плюс коммерческий провайдер или Tor как выходная.
  

Источники​

• Коммерческий VPN | Surveillance Self-Defense
  
• WireGuard: fast, modern, secure VPN tunnel