Почему VPN не работает: DPI, блокировки, утечки DNS и что реально помогает в 2025-2026

Почему VPN не работает: DPI, блокировки, утечки DNS и что реально помогает в 2025-2026
Быстрый ответ
VPN перестал работать потому что:
  • Провайдер распознаёт протокол через DPI и режет соединение ещё до установки туннеля
  • DNS-запросы уходят мимо тоннеля напрямую к серверам провайдера — ты «анонимен», но тебя видно насквозь
  • WireGuard имеет фиксированную сигнатуру (handshake 148 байт) — ТСПУ блокирует его без проблем с середины 2025 года
  • Классические протоколы OpenVPN и IPSec давно в чёрных списках у крупных провайдеров

Работающее решение: AmneziaWG 2.0 (обфусцированный WireGuard) или Tailscale через Headscale для mesh-сетей. Ниже — разбор каждой проблемы с командами и конфигами.

Содержание: показать

Диагноз: VPN включён, но ничего не изменилось

Почему VPN не работает — вопрос который в 2025 году задают десятки тысяч людей одновременно. Ты настроил VPN, подключился, иконка горит. Но сайт не открывается. Или открывается, но провайдер всё равно видит куда ты ходишь. Или скорость упала до нуля и через 30 секунд соединение рвётся.

Это не баг конкретного клиента. Это системная проблема — мир изменился, а большинство VPN-гайдов в интернете застряли в 2019 году.

Есть три принципиально разных сценария когда «VPN не работает», и их нужно различать. Первый — туннель вообще не поднимается, DPI блокирует handshake ещё до установки соединения. Второй — туннель работает, IP сменился, но DNS течёт мимо — провайдер видит все твои домены. Третий — туннель и DNS в порядке, но конкретные сайты заблокированы на уровне IP и твой VPS тоже в этом списке. Для каждого сценария — своё решение, и я разберу все три.

Что разберём в этой статье:

  • Как работает DPI и почему он распознаёт твой VPN-трафик
  • Что такое ТСПУ и почему с сентября 2025 года стало хуже
  • Почему WireGuard блокируют как по учебнику
  • Как утечка DNS сводит на нет всю защиту
  • AmneziaWG 2.0 — практическая настройка с нуля
  • Tailscale vs WireGuard — когда что выбирать
  • Выбор VPS, безопасность сервера, мониторинг

Времени потребуется: 20-40 минут на чтение и настройку. Нужен VPS или сервер за пределами зоны блокировок.

Краткая история: как VPN превратился из инструмента в мишень

В 2015 году настроить VPN означало: поднял OpenVPN на DigitalOcean, скопировал .ovpn файл на телефон, готово. Всё работало потому что провайдеры смотрели только на порты и IP-адреса. Если порт 1194 UDP не в чёрном списке — проходи.

Потом появились реестры заблокированных IP. Провайдеры начали блокировать целые подсети дата-центров. Все быстро переехали на случайные порты и менее известные VPS-провайдеры. Кошки-мышки, раунд один.

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

Раунд три — 2025 год. В ТСПУ включили ML-классификаторы. Теперь система не ищет конкретные байты в заголовках — она анализирует поведение трафика в целом. Размер пакетов, временные паттерны, соотношение входящего и исходящего, энтропия данных. WireGuard заблокировали первым потому что его паттерны слишком характерны. OpenVPN лежит давно. IPSec выживает только в корпоративных исключениях.

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

Как провайдер видит твой VPN-трафик: DPI изнутри

DPI — Deep Packet Inspection, глубокая инспекция пакетов. Это не волшебство и не слежка в голливудском смысле. Это промышленная система анализа трафика которая стоит между тобой и интернетом.

Классический файрвол смотрит только на заголовки пакетов: IP-адрес источника, порт назначения. DPI смотрит глубже — на структуру самого пакета, размеры, интервалы между пакетами, паттерны handshake.

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#ffffff',
    'primaryTextColor': '#1e293b',
    'primaryBorderColor': '#94a3b8',
    'lineColor': '#64748b',
    'fontSize': '15px',
    'fontFamily': 'ui-sans-serif, system-ui, sans-serif'
  },
  'flowchart': {'curve': 'linear', 'nodeSpacing': 50, 'rankSpacing': 50}
}}%%
flowchart TD
    A["Твой компьютер"] --> B["Пакет выходит в сеть"]
    B --> C["DPI / ТСПУ"]
    C --> D["Анализ: что за протокол?"]
    D --> E["Известная сигнатура WireGuard?"]
    E --> F["Блокировка / RST"]
    E --> G["Нет сигнатуры - пропускаем"]
    G --> H["VPN-сервер"]
    style A fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style F fill:#f8fafc,stroke:#ef4444,stroke-width:2px,color:#dc2626
    style H fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d
    style C fill:#f8fafc,stroke:#f97316,stroke-width:2px,color:#c2410c

DPI умеет несколько вещей которые делают обычный VPN бесполезным:

Метод DPI Что анализирует Что блокирует
Сигнатурный анализ Первые байты пакета, структура handshake OpenVPN, WireGuard, IPSec по шаблону
Поведенческий анализ Размеры пакетов, временные паттерны Зашифрованные туннели с характерным ритмом
Статистический анализ Распределение длин пакетов, энтропия Трафик с нетипично высокой энтропией (= шифрование)
ML-классификация Комбинация всех параметров Даже обфусцированные протоколы если ML обучен
Active Probing DPI сам подключается к твоему серверу и проверяет VPN-серверы по результату зондирования

В России это реализовано через ТСПУ — Технические Средства Противодействия Угрозам. К 2026 году ТСПУ покрывает более 95% интернет-трафика страны. С сентября 2025 года в системе включены ML-алгоритмы нового поколения которые блокируют большинство классических VPN-протоколов автоматически.

Почему WireGuard заблокировали первым

WireGuard — отличный протокол. Быстрый, простой, криптографически безупречный. И именно поэтому его заблокировали раньше всех остальных.

Проблема в предсказуемости. WireGuard handshake initiation всегда имеет фиксированный размер — 148 байт. Первые четыре байта UDP-пакета всегда [0x01, 0x00, 0x00, 0x00]. Это цифровой отпечаток на лбу.

DPI не нужно расшифровывать содержимое. Ему достаточно увидеть:

  • UDP-пакет размером 148 байт
  • Первые байты совпадают с WireGuard Handshake Initiation
  • Через 92 байта приходит ответ (Handshake Response)

Готово — соединение убито RST-пакетом ещё до завершения рукопожатия. Туннель не поднялся ни разу.


# Проверь - твой WireGuard блокируется до handshake или после
# Запусти tcpdump на клиенте во время подключения
sudo tcpdump -i eth0 udp port 51820 -v

# Если видишь 148-байтный исходящий пакет без ответа - DPI блокирует на входе
# Если видишь SYN/RST - блокировка по IP

С середины 2025 года обычный WireGuard перестал работать через большинство российских операторов. Это не слухи — это подтверждённый факт от пользователей на Хабре и GitHub.

Кстати, аналогичная история произошла с WireGuard в Египте ещё в 2021 году — DPI научился распознавать Handshake Initiate пакеты по фиксированному размеру 148 байт и первым четырём байтам [0x01, 0x00, 0x00, 0x00]. Россия прошла тот же путь, только позже. И решение такое же: убрать предсказуемость.

Ещё одна причина почему WireGuard лёгкая мишень — он работает строго по UDP. Это само по себе сигнал для DPI. Большинство легитимного трафика ходит по TCP. Длинная UDP-сессия с характерными размерами пакетов — именно тот паттерн который DPI ищет в первую очередь.

AmneziaWG: как WireGuard научился прятаться

AmneziaWG — форк WireGuard от команды Amnezia VPN. Криптографическое ядро не тронуто: Curve25519, ChaCha20-Poly1305, BLAKE2s — всё то же самое. Поменяли только транспортный слой.

Первая версия AmneziaWG 1.x заменяла стандартные заголовки фиксированными кастомными значениями. Помогло ненадолго — DPI обучился на новых статических значениях так же быстро как на старых. Версия 2.0 пошла другим путём: вместо замены фиксированных значений на другие фиксированные — рандомизация при каждом соединении.

AmneziaWG 2.0 (выпущен в конце 2025 года) делает следующее:

  • Рандомизирует заголовки всех типов пакетов — handshake initiation, handshake response, data packet, under-load packet
  • Использует динамические диапазоны значений заголовков вместо статических
  • Добавляет случайный паддинг к пакетам — размер больше не предсказуем
  • Имитирует паттерны трафика популярных UDP-протоколов
  • Добавляет junk-пакеты перед handshake — это параметры Jc, Jmin, Jmax в конфиге

DPI видит случайный поток UDP-пакетов с непредсказуемыми заголовками. Никакой знакомой сигнатуры — нечего блокировать.

Важный момент про параметры Jc/S1/S2: эти значения должны быть одинаковы на сервере и клиенте — это не ключи шифрования, а просто договорённость о формате пакетов. Но при этом они должны быть уникальными для твоей инсталляции. Если ты скопировал значения из публичного гайда (как это сделали тысячи людей) — DPI просто добавит эту комбинацию в базу сигнатур. Генерируй свои.

Установка AmneziaWG сервера на Ubuntu/Debian

Требования
VPS за пределами зоны блокировок. Ubuntu 22.04 или 24.04, Debian 11/12. Root-доступ. Минимум 512 МБ RAM. На момент публикации актуальна AmneziaWG 2.0. Перед установкой проверь свежие релизы на github.com/amnezia-vpn/amneziawg-linux-kernel-module

# Обновляем систему
apt update && apt upgrade -y

# Устанавливаем зависимости
apt install -y wireguard-tools linux-headers-$(uname -r) build-essential git

# Клонируем репозиторий AmneziaWG
git clone https://github.com/amnezia-vpn/amneziawg-linux-kernel-module.git
cd amneziawg-linux-kernel-module

# Собираем и устанавливаем модуль ядра
make
make install

# Загружаем модуль
modprobe amneziawg

# Проверяем что модуль загружен
lsmod | grep amnezia


# Генерируем ключи сервера
awg genkey | tee /etc/amnezia/server_private.key | awg pubkey > /etc/amnezia/server_public.key

# Генерируем ключи клиента
awg genkey | tee /etc/amnezia/client_private.key | awg pubkey > /etc/amnezia/client_public.key

# Просматриваем ключи - они понадобятся для конфигов
cat /etc/amnezia/server_private.key
cat /etc/amnezia/server_public.key
cat /etc/amnezia/client_private.key
cat /etc/amnezia/client_public.key

Конфиг сервера с обфускацией. Параметры Jc, Jmin, Jmax, S1, S2, H1-H4 — это магия AmneziaWG. Они рандомизируют заголовки и добавляют junk-пакеты перед handshake:


# /etc/amnezia/awg0.conf - серверный конфиг
[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = ТВОЙ_ПРИВАТНЫЙ_КЛЮЧ_СЕРВЕРА

# Обфускация AmneziaWG 2.0 - рандомизирует сигнатуру
Jc = 5
Jmin = 50
Jmax = 1000
S1 = 30
S2 = 40
H1 = 1234567891
H2 = 1234567892
H3 = 1234567893
H4 = 1234567894

# IP-форвардинг и NAT
PostUp = iptables -A FORWARD -i awg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i awg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = ПУБЛИЧНЫЙ_КЛЮЧ_КЛИЕНТА
AllowedIPs = 10.8.0.2/32
Важно про H1-H4
Значения H1-H4 в примере — учебные. Для продакшна сгенерируй свои случайные 32-битные числа командой ниже. Одинаковые значения у всех пользователей — это новая сигнатура для DPI.

# Генерируем уникальные H1-H4 для своей инсталляции
for i in 1 2 3 4; do echo "H$i = $(od -A n -t d4 -N 4 /dev/urandom | tr -d ' ')"; done


# Запускаем интерфейс AmneziaWG
awg-quick up /etc/amnezia/awg0.conf

# Включаем автозапуск
systemctl enable awg-quick@awg0

# Включаем IP-форвардинг на сервере
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
sysctl -p

Конфиг клиента — зеркальная структура с параметрами обфускации:


# Клиентский конфиг awg-client.conf
[Interface]
Address = 10.8.0.2/24
PrivateKey = ТВОЙ_ПРИВАТНЫЙ_КЛЮЧ_КЛИЕНТА
DNS = 1.1.1.1

# Те же параметры обфускации что и на сервере - должны совпадать
Jc = 5
Jmin = 50
Jmax = 1000
S1 = 30
S2 = 40
H1 = 1234567891
H2 = 1234567892
H3 = 1234567893
H4 = 1234567894

[Peer]
PublicKey = ПУБЛИЧНЫЙ_КЛЮЧ_СЕРВЕРА
Endpoint = IP_СЕРВЕРА:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

Проверка что AmneziaWG работает


# На сервере - проверяем статус
awg show

# Должно показать интерфейс awg0, пиров и last handshake
# Если latest handshake есть - туннель работает

# На клиенте Linux
awg-quick up /path/to/awg-client.conf
curl ifconfig.me
# Должен показать IP твоего VPS, а не домашний IP

Утечка DNS: анонимность со сквозняком

Вот сценарий который встречается у 40% пользователей VPN. Туннель поднят. IP поменялся. Но DNS-запросы уходят мимо туннеля — напрямую к серверам провайдера.

Что это означает на практике: провайдер не видит твои HTTP-запросы, но видит все DNS-резолвы. То есть знает каждый домен который ты посетил. ТСПУ анализирует DNS-трафик на магистральных каналах и использует его для блокировки ресурсов и детекции самого факта использования VPN.

Почему DNS вообще может уйти мимо туннеля? Несколько механизмов.

Первый — DNS не указан в конфиге VPN-клиента. Операционная система использует свои настройки DNS которые были до VPN, то есть сервер провайдера. Решается добавлением строки DNS в секцию [Interface] конфига WireGuard.

Второй — операционная система игнорирует DNS из конфига VPN. Windows особенно грешит этим через механизм Smart Multi-Homed Name Resolution: если один DNS-сервер отвечает медленно, Windows спрашивает все доступные серверы параллельно и берёт первый ответ. Первым обычно отвечает провайдерский DNS, он рядом.

Третий — IPv6 DNS утечка. Если в AllowedIPs не прописан ::/0, весь IPv6-трафик включая DNS идёт напрямую. Современные операционные системы активно используют IPv6 когда он доступен.

Четвёртый — split DNS. Некоторые корпоративные VPN настроены так что только корпоративные домены идут через туннель, остальное — напрямую. В этом случае все твои личные запросы видит провайдер.

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#ffffff',
    'primaryTextColor': '#1e293b',
    'primaryBorderColor': '#94a3b8',
    'lineColor': '#64748b',
    'fontSize': '15px',
    'fontFamily': 'ui-sans-serif, system-ui, sans-serif'
  },
  'flowchart': {'curve': 'linear', 'nodeSpacing': 50, 'rankSpacing': 50}
}}%%
flowchart TD
    A["Твой браузер"] --> B["DNS-запрос: example.com?"]
    B --> C{Куда идёт DNS?}
    C --> D["Через VPN-туннель"]
    C --> E["Мимо туннеля к провайдеру"]
    D --> F["DNS-сервер VPN или 1.1.1.1"]
    E --> G["DNS провайдера - УТЕЧКА"]
    G --> H["Провайдер знает все твои сайты"]
    F --> I["Анонимность сохранена"]
    style A fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style E fill:#f8fafc,stroke:#ef4444,stroke-width:2px,color:#dc2626
    style G fill:#f8fafc,stroke:#ef4444,stroke-width:2px,color:#dc2626
    style I fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d

Как проверить утечку DNS


# Быстрая проверка в терминале
# Без VPN - запомни какой DNS показывает
dig +short myip.opendns.com @resolver1.opendns.com

# Включи VPN и проверь снова
dig +short myip.opendns.com @resolver1.opendns.com

# Если оба раза один и тот же IP - VPN не работает
# Если разные - хорошо, но DNS может всё равно течь

# Проверяем именно DNS-резолвер
nslookup whoami.akamai.net
# Ответ должен быть с IP твоего VPS или публичного DoH-резолвера

Также используй онлайн-сервисы: dnsleaktest.com или browserleaks.com/dns. Запусти тест дважды — до и после включения VPN. DNS-серверы в результате должны смениться.

Как исправить утечку DNS в WireGuard/AmneziaWG

Причина утечки обычно одна из трёх: DNS не указан в конфиге клиента, AllowedIPs не включает DNS-трафик, или операционная система игнорирует DNS из конфига (привет, Windows с его Smart Multi-Homed Name Resolution).


# В клиентском конфиге WireGuard/AmneziaWG обязательно:
[Interface]
DNS = 1.1.1.1, 1.0.0.1
# Или используй DNS своего VPS: 10.8.0.1 (если поднял unbound/dnsmasq там)

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
# AllowedIPs = 0.0.0.0/0 - весь IPv4 трафик через туннель
# ::/0 - весь IPv6, иначе DNS через IPv6 утечёт мимо


# На сервере поднять локальный DNS чтобы не светить 1.1.1.1 в логах
apt install -y unbound

# Минимальный конфиг unbound - слушает только на интерфейсе VPN
cat > /etc/unbound/unbound.conf.d/vpn.conf << 'EOF'
server:
    interface: 10.8.0.1
    access-control: 10.8.0.0/24 allow
    hide-identity: yes
    hide-version: yes
    use-caps-for-id: yes
    prefetch: yes
EOF

systemctl restart unbound
systemctl enable unbound


# Windows: отключить Smart Multi-Homed Name Resolution через реестр
# (причина №1 утечек DNS на Windows даже при правильном конфиге WG)
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" /v DisableSmartNameResolution /t REG_DWORD /d 1 /f

# Проверить результат - запусти после изменения:
ipconfig /flushdns
# И снова тест на dnsleaktest.com

Tailscale и WireGuard: когда что выбирать

Tailscale часто рекламируют как «WireGuard только проще». Это правда, но неполная.

Tailscale — это продукт поверх WireGuard. Он добавляет control plane: автоматическое обнаружение устройств, обмен ключами, NAT traversal, MagicDNS, ACL. Ты не пишешь конфиги вручную — просто устанавливаешь клиент и устройства видят друг друга.

Проблема в том что control plane Tailscale — закрытый код и хостится у Tailscale Inc. Они не могут читать твой трафик (шифрование end-to-end на WireGuard), но видят метаданные: какие устройства онлайн, с каких IP подключаются. Для корпоративной среды это серьёзный вопрос.

Другая проблема Tailscale в контексте этой статьи: он не решает задачу обхода DPI для исходящего трафика. Tailscale отлично подходит чтобы с телефона достучаться до домашнего NAS или до рабочего сервера. Но если цель — выходить в интернет через VPS обходя блокировки — для этого нужен exit node, и его трафик всё равно идёт через WireGuard который может быть заблокирован. AmneziaWG решает именно задачу выхода в интернет через обфусцированный туннель.

По факту это не конкуренты, а инструменты для разных задач. У меня в инфраструктуре оба: Tailscale для mesh-доступа к своим сервисам, AmneziaWG для выхода в интернет.

Критерий WireGuard (self-hosted) Tailscale (облако) Headscale (self-hosted)
Сложность настройки Высокая — конфиги вручную Минимальная — 5 минут Средняя
Control plane Нет — ты сам Tailscale Inc. Твой сервер
NAT traversal Вручную / не всегда Автоматически Автоматически
Утечка метаданных Нет К Tailscale Inc. Нет
CGNAT/Starlink Сложно Работает Работает
Обход DPI Нет (нужен AmneziaWG) Частично Частично
Цена Бесплатно Free/20$/мес Бесплатно
Подходит для Site-to-site, продакшн Homelab, команды Privacy-ориентированный homelab

Tailscale выигрывает когда ты за CGNAT или Starlink, когда нужно быстро подключить несколько устройств без возни с конфигами, когда в команде есть нетехнические люди. Чистый WireGuard — когда нужен полный контроль, site-to-site между роутерами, или ты строишь что-то для продакшна где зависимость от внешнего сервиса недопустима.

Headscale: Tailscale без Tailscale

Headscale — open-source реализация control server от Tailscale. Разворачиваешь на своём VPS и получаешь всю удобность Tailscale без зависимости от их инфраструктуры.


# Установка Headscale на Ubuntu
HEADSCALE_VERSION=$(curl -s https://api.github.com/repos/juanfont/headscale/releases/latest | grep tag_name | cut -d '"' -f 4)
wget "https://github.com/juanfont/headscale/releases/download/${HEADSCALE_VERSION}/headscale_linux_amd64"
chmod +x headscale_linux_amd64
mv headscale_linux_amd64 /usr/local/bin/headscale

# Создаём конфиг директорию
mkdir -p /etc/headscale /var/lib/headscale

# Скачиваем пример конфига
wget https://raw.githubusercontent.com/juanfont/headscale/main/config-example.yaml \
  -O /etc/headscale/config.yaml

# Правим server_url на свой домен/IP
# После - запускаем
headscale serve

# Создаём пользователя и генерируем ключ для клиента
headscale users create myuser
headscale preauthkeys create --user myuser --reusable --expiration 24h

Другие утечки: WebRTC и IPv6

DNS — самая частая утечка, но не единственная.

WebRTC — браузерный протокол для видеозвонков. Он умеет определять реальный IP даже за NAT и даже при включённом VPN через STUN-серверы. Если ты открываешь meet.google.com или Discord в браузере с включённым VPN — есть шанс что WebRTC засветил твой домашний IP.

Механизм такой: браузер запрашивает STUN-сервер (stun.google.com и подобные) для определения своего публичного IP. Этот запрос идёт в обход VPN-туннеля на уровне браузера, а не операционной системы. VPN-клиент который работает как сетевой интерфейс — не видит этот трафик.


# Проверить WebRTC утечку можно на:
# https://browserleaks.com/webrtc
# или https://ipleak.net

# Отключить WebRTC в Firefox через about:config:
# media.peerconnection.enabled = false

# Chrome/Edge - только через расширение WebRTC Network Limiter
# или через режим "Route all traffic through VPN" в настройках системы

IPv6 — ещё одна дыра. WireGuard по умолчанию роутит только IPv4 если не указать явно ::/0 в AllowedIPs. Все IPv6-запросы уходят напрямую. Если у твоего провайдера есть IPv6 (а у большинства в 2025 году он есть) — ты светишься по IPv6 даже при правильно настроенном IPv4-туннеле.


# Проверяем есть ли IPv6 утечка
curl -6 ifconfig.me
# Если ответил - IPv6 работает напрямую

# Решение 1: добавить в AllowedIPs клиентского конфига
# AllowedIPs = 0.0.0.0/0, ::/0

# Решение 2: отключить IPv6 на интерфейсе если VPS его не поддерживает
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1

Системные требования

Компонент Минимум Рекомендуется
ОС сервера (VPS) Ubuntu 20.04 / Debian 11 Ubuntu 24.04 / Debian 12
Ядро Linux 5.4+ 6.1+ (нативный WireGuard в ядре)
AmneziaWG 2.0 (конец 2025) Последний релиз с GitHub
Tailscale 1.70+ Последний стабильный
Headscale 0.23+ Последний релиз
RAM сервера 512 МБ 1 ГБ (с unbound DNS)
ОС клиента Windows 10, Android 8, iOS 15 Windows 11, Android 12+, iOS 16+

Порты и фаервол

Порт Протокол Назначение Открыт снаружи
51820 UDP WireGuard / AmneziaWG Да
41641 UDP Tailscale DERP relay Нет (исходящий)
853 TCP DNS over TLS (часто блокируется) Нет
443 TCP/UDP DoH, QUIC-маскировка Нет (исходящий)
53 UDP Локальный unbound DNS Нет (только LAN) 

# Минимальная настройка UFW на VPS
ufw allow ssh
ufw allow 51820/udp
ufw enable

# Проверяем что правила применились
ufw status verbose

Выбор VPS: где поднимать сервер и на что смотреть

Даже идеально настроенный AmneziaWG не поможет если IP твоего сервера уже в чёрных списках. Это первое на что нужно смотреть при выборе VPS для VPN.

Проверь IP перед покупкой. Большинство хостингов позволяют узнать IP заранее или дают тестовый период. Прогони через базы блокировок и через простой тест — просто зайди на заблокированный в твоей стране сайт напрямую с этого IP через curl:


# Проверяем с сервера - доступен ли условно заблокированный ресурс
curl -I --max-time 10 https://example-blocked-site.com

# Проверяем что IP не в спам-листах
curl "https://api.abuseipdb.com/api/v2/check?ipAddress=$(curl -s ifconfig.me)" \
  -H "Key: ВАШ_API_KEY" \
  -H "Accept: application/json"

Географически лучше брать серверы в Финляндии, Нидерландах, Германии или в Прибалтике. Они близко по пингу к России, хорошая связность, и эти страны не участвуют в массовой блокировке VPS-провайдеров. Американские и азиатские серверы работают, но пинг выше.

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

Отдельный момент: некоторые операторы блокируют не конкретные IP, а целые ASN (автономные системы) крупных хостингов. DigitalOcean ASN, Hetzner ASN, Vultr ASN — в отдельных сетях они могут быть заблокированы полностью. Если VPS на Hetzner не работает — попробуй менее популярный хостинг с другим ASN.

Безопасность VPN-сервера: минимальный чеклист

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

SSH hardening. Первым делом меняй порт и запрещай вход по паролю:


# Редактируем /etc/ssh/sshd_config
# Меняем порт с 22 на произвольный
Port 2222

# Запрещаем вход root по SSH
PermitRootLogin no

# Запрещаем вход по паролю
PasswordAuthentication no

# Перезапускаем SSH (не закрывай текущую сессию до проверки!)
systemctl restart sshd

# Открываем новый порт в UFW
ufw allow 2222/tcp


# fail2ban - защита от брутфорса SSH
apt install -y fail2ban

# Конфиг для SSH
cat > /etc/fail2ban/jail.local << 'EOF'
[sshd]
enabled = true
port = 2222
maxretry = 3
bantime = 3600
findtime = 600
EOF

systemctl enable fail2ban
systemctl start fail2ban

# Проверяем статус
fail2ban-client status sshd

Закрываем всё лишнее. После установки AmneziaWG на сервере должны быть открыты только два порта: SSH (твой кастомный) и UDP 51820 для VPN. Всё остальное — закрыто:


# Проверяем текущие правила
ufw status verbose

# Должно быть примерно так:
# 2222/tcp  ALLOW IN
# 51820/udp ALLOW IN
# Всё остальное - DENY

# Если что-то лишнее открыто:
ufw delete allow 80/tcp  # например если открыли для проверки

Автоматические обновления безопасности. Сервер должен получать security-патчи без твоего участия. Прострел через незакрытую уязвимость ядра — классическая история:


apt install -y unattended-upgrades

# Активируем автообновления безопасности
dpkg-reconfigure --priority=low unattended-upgrades

# Проверяем конфиг
cat /etc/apt/apt.conf.d/50unattended-upgrades | grep -A5 "Unattended-Upgrade::Allowed"

Один пользователь для VPN. Не запускай awg-quick от root в продакшне. Создай отдельного пользователя с минимальными правами:


# Создаём системного пользователя для VPN
useradd -r -s /sbin/nologin vpnuser

# Даём права на управление интерфейсом через sudo
echo "vpnuser ALL=(root) NOPASSWD: /usr/bin/awg-quick" >> /etc/sudoers.d/vpnuser
chmod 440 /etc/sudoers.d/vpnuser

Клиенты AmneziaWG: что ставить на телефон и ноутбук

Официальные клиенты AmneziaWG поддерживают Android, iOS, Windows, macOS и Linux. Это важно: нельзя использовать обычный клиент WireGuard с конфигом AmneziaWG — он не понимает параметры обфускации и просто их игнорирует, работая как чистый WireGuard.

Android: приложение AmneziaWG доступно на GitHub releases и в F-Droid. В Google Play может быть устаревшая версия — лучше брать с GitHub.

iOS: приложение AmneziaVPN в App Store. Поддерживает AmneziaWG конфиги, импорт через QR-код или файл.

Windows: клиент доступен на официальном сайте amnezia.org. Поддерживает импорт .conf файла. Убедись что версия не старше 4.x — старые клиенты не поддерживают AWG 2.0 параметры.

Linux: можно использовать awg-quick напрямую (как в этой статье) или установить GUI клиент. Для headless серверов awg-quick через systemd — это всё что нужно.


# Генерируем QR-код для импорта на мобильное устройство
# (на сервере, устанавливаем qrencode)
apt install -y qrencode

# Генерируем QR из клиентского конфига
qrencode -t ANSIUTF8 < /etc/amnezia/client.conf

# Или сохраняем как PNG
qrencode -t PNG -o /tmp/vpn-client-qr.png < /etc/amnezia/client.conf

Важный момент для мобильных: на Android и iOS VPN-клиент должен быть настроен как Always-on VPN с опцией Block connections without VPN. Это предотвращает утечку трафика в момент переключения между WiFi и мобильным интернетом — именно тогда чаще всего происходят DNS-утечки на мобильных устройствах.

Проверка через tcpdump: что реально уходит в сеть

Онлайн-тесты удобны, но иногда нужно видеть трафик своими глазами. tcpdump — твой главный инструмент диагностики когда что-то идёт не так.


# Смотрим весь DNS-трафик на клиентской машине
# -n не резолвить имена, -i any все интерфейсы, port 53 только DNS
sudo tcpdump -n -i any port 53

# Включи VPN и посмотри что происходит
# Если видишь DNS-запросы с интерфейса не-VPN - это утечка
# Нормально: DNS только через интерфейс туннеля (wg0, awg0, utun)


# Проверяем что WireGuard/AmneziaWG трафик идёт через нужный интерфейс
sudo tcpdump -n -i eth0 udp port 51820

# Должно показывать UDP-пакеты с твоим IP и IP сервера
# Если пакеты есть - туннель поднимается
# Если пакетов нет после wg-quick up - проверь firewall на клиенте


# Проверяем маршрутизацию - куда идут пакеты
ip route get 8.8.8.8
# Должно показать через интерфейс VPN: dev awg0

# Если показывает физический интерфейс - маршрут не прописался
# Проверь AllowedIPs в конфиге - должен быть 0.0.0.0/0

Ещё один полезный трюк — посмотреть на статистику интерфейса до и после тестирования. Если байты растут только на VPN-интерфейсе — трафик идёт туда куда надо:


# Статистика интерфейсов
watch -n 1 'cat /proc/net/dev | grep -E "awg0|eth0|wg0"'
# Открываешь сайт - смотришь на каком интерфейсе растут RX/TX байты
Симптом Причина Решение
Handshake не проходит, соединение рвётся через 30 сек DPI блокирует WireGuard по сигнатуре Переход на AmneziaWG с обфускацией, уникальные H1-H4
Туннель поднят, IP сменился, но DNS светит провайдера DNS не идёт через туннель (утечка) Указать DNS в конфиге, AllowedIPs = 0.0.0.0/0, ::/0
VPN работает, но IPv6 не через туннель AllowedIPs не включает IPv6 Добавить ::/0 в AllowedIPs или отключить IPv6
Туннель работает, но сайты иногда не открываются MTU mismatch — WireGuard overhead Установить MTU 1380 в [Interface] обоих конфигов
После подключения пропал интернет полностью IP-форвардинг выключен на сервере или PostUp не сработал sysctl net.ipv4.ip_forward=1, проверить iptables правила
AmneziaWG клиент не видит сервер Параметры Jc/S1/S2/H1-H4 не совпадают на клиенте и сервере Скопировать параметры обфускации точно, без изменений
Tailscale не устанавливает прямое соединение, идёт через relay Оба устройства за строгим NAT Настроить exit node или subnet router на VPS
awg: command not found после установки модуля Пакет wireguard-tools не установлен или awg не в PATH apt install wireguard-tools, проверить /usr/bin/awg

Разбор типичных ситуаций из практики

Теория это хорошо, но давай разберём конкретные сценарии которые встречаются чаще всего.

Ситуация первая: WireGuard работал, потом перестал. Без изменений с твоей стороны. Это классика. Провайдер обновил ТСПУ или активировал новое правило. Первый шаг диагностики: проверь тот же конфиг через мобильный интернет (другой провайдер). Если через мобильный работает — проблема у конкретного домашнего провайдера. Решение: переход на AmneziaWG или смена порта. Если и через мобильный не работает — IP VPS заблокирован. Смени IP или хостинг.

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

Ситуация третья: VPN работает дома, не работает на работе или в другом месте. Скорее всего корпоративная сеть или сеть отеля блокирует исходящий UDP 51820. Решение: поднять второй экземпляр AmneziaWG на порту 443 UDP. Этот порт блокируют крайне редко. Альтернатива — VLESS Reality на TCP 443, это вообще неотличимо от обычного HTTPS.

Ситуация четвёртая: скорость через VPN в 3-5 раз ниже чем без VPN. Первое что проверяем — MTU. Установи в конфиге клиента MTU = 1380 и перезапусти туннель. Второе — физическое расстояние до VPS. Если сервер в Сингапуре а ты в Москве — 100+ мс пинга это физика, не баг. Третье — throttling. Некоторые провайдеры специально режут скорость VPN-трафика не блокируя его полностью. Обфускация через AmneziaWG помогает и здесь — трафик выглядит как обычный UDP и не попадает в правила throttling.


# Диагностика MTU - ищем оптимальный размер
# Пингуем с размером пакета и смотрим когда начинают дропаться
ping -M do -s 1450 IP_СЕРВЕРА
ping -M do -s 1400 IP_СЕРВЕРА
ping -M do -s 1350 IP_СЕРВЕРА
# Первый размер при котором пинг проходит - добавь 28 (IP+ICMP заголовки)
# Это и есть твой оптимальный MTU для WireGuard интерфейса


# Тест скорости через туннель
# Установи iperf3 на сервере и клиенте
# На сервере:
iperf3 -s

# На клиенте (при активном VPN-туннеле):
iperf3 -c IP_СЕРВЕРА -t 10
# Если скорость нормальная - проблема не в туннеле
# Если низкая - MTU или throttling

Ситуация пятая: на Android VPN постоянно отключается в фоне. Это оптимизация батареи убивает VPN-процесс. На Android нужно: добавить AmneziaWG или Tailscale в исключения из оптимизации батареи, включить Always-on VPN в настройках сети (Настройки — Сеть — VPN — шестерёнка у нужного VPN), и убедиться что включена опция Block connections without VPN. После этого система не будет убивать VPN-процесс.

Ситуация шестая: IPv6 работает а IPv4 через туннель не идёт. Странный сценарий но бывает. Проверь что PostUp правила в конфиге сервера применились — запусти iptables -t nat -L POSTROUTING на сервере. Если правила есть но трафик не идёт — проверь net.ipv4.ip_forward через sysctl net.ipv4.ip_forward. Должно быть 1. После каждой перезагрузки значение сбрасывается если не прописать в /etc/sysctl.conf.

DNS-over-HTTPS: дополнительная защита поверх VPN

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

Решение: настроить Unbound использовать DoH (DNS-over-HTTPS) или DoT (DNS-over-TLS) к доверенному резолверу. Cloudflare 1.1.1.1, Quad9 9.9.9.9 или Mullvad DNS поддерживают оба протокола.


# Устанавливаем dnscrypt-proxy для DoH
apt install -y dnscrypt-proxy

# Конфиг dnscrypt-proxy
cat > /etc/dnscrypt-proxy/dnscrypt-proxy.toml << 'EOF'
listen_addresses = ['127.0.0.1:5300']
server_names = ['cloudflare', 'cloudflare-ipv6']
require_dnssec = true
require_nolog = true
require_nolog = true
EOF

systemctl enable dnscrypt-proxy
systemctl start dnscrypt-proxy


# Настраиваем Unbound использовать dnscrypt-proxy как upstream
# Добавляем в /etc/unbound/unbound.conf.d/vpn.conf:
cat >> /etc/unbound/unbound.conf.d/vpn.conf << 'EOF'
forward-zone:
    name: "."
    forward-addr: 127.0.0.1@5300
EOF

systemctl restart unbound

# Проверяем что DNS резолвится через наш стек
dig @10.8.0.1 example.com
# Должен отвечать с минимальной задержкой

Теперь цепочка полная: браузер — AmneziaWG туннель — Unbound на сервере — dnscrypt-proxy (DoH) — Cloudflare. Каждый уровень шифрует и изолирует DNS от провайдера.

Настроил один раз — не значит работает вечно. DPI-системы обновляются, сигнатуры меняются, блокировки расширяются. Несколько практик которые снижают вероятность «опять не работает».

Мониторинг туннеля. Простой скрипт который проверяет что last handshake был недавно и пингует внешний IP через туннель:


#!/bin/bash
# /usr/local/bin/check-vpn.sh - запускать через cron каждые 5 минут

PEER_PUBKEY="ПУБЛИЧНЫЙ_КЛЮЧ_КЛИЕНТА"
MAX_HANDSHAKE_AGE=300  # 5 минут в секундах

LAST_HANDSHAKE=$(awg show awg0 latest-handshakes | grep "$PEER_PUBKEY" | awk '{print $2}')
NOW=$(date +%s)
AGE=$((NOW - LAST_HANDSHAKE))

if [ "$AGE" -gt "$MAX_HANDSHAKE_AGE" ]; then
    echo "$(date): Peer $PEER_PUBKEY handshake too old (${AGE}s), restarting tunnel"
    systemctl restart awg-quick@awg0
fi


# Добавляем в cron
(crontab -l; echo "*/5 * * * * /usr/local/bin/check-vpn.sh >> /var/log/vpn-check.log 2>&1") | crontab -

Резервный порт. Если порт 51820 начали блокировать — у тебя должен быть запасной. Добавь второй ListenPort в конфиге сервера или подними второй экземпляр на порту 443 UDP. Блокировку 443 UDP провайдеры избегают — там сидит QUIC/HTTP3.


# Проверяем что порт 51820 UDP реально достижим с клиентской стороны
# (запускаем на сервере)
nc -u -l 51820 &
# На клиенте:
echo "test" | nc -u IP_СЕРВЕРА 51820
# Если на сервере пришло "test" - порт открыт

Бэкап конфигов. Кажется очевидным, но после пятого «перенастрой мне VPN» от знакомых я убедился что нет.


# Бэкапим все ключи и конфиги
tar czf /root/vpn-backup-$(date +%Y%m%d).tar.gz /etc/amnezia/ /etc/wireguard/

# Проверяем что бэкап читается
tar tzf /root/vpn-backup-*.tar.gz | head -20

Как обновлять AmneziaWG безопасно

AmneziaWG — kernel module. Обновление требует пересборки модуля под новое ядро. Если сначала обновить ядро а потом забыть пересобрать модуль — после перезагрузки VPN не поднимется. Алгоритм обновления такой:


# 1. Проверяем текущую версию модуля
modinfo amneziawg | grep version

# 2. Перед обновлением системы - сохрани рабочий конфиг
awg showconf awg0 > /root/awg0-backup-$(date +%Y%m%d).conf

# 3. Обновляем систему
apt update && apt upgrade -y

# 4. Проверяем версию ядра - изменилась ли
uname -r

# 5. Если ядро обновилось - пересобираем модуль
cd /root/amneziawg-linux-kernel-module
git pull
make clean
make
make install
modprobe amneziawg

# 6. Перезапускаем туннель
systemctl restart awg-quick@awg0

# 7. Проверяем
awg show

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

Альтернативы: когда AmneziaWG не помогает

Бывает что и AmneziaWG не проходит — особенно на некоторых мобильных операторах где DPI особенно агрессивный. Вот что пробовать дальше.

VLESS + Reality — протокол из экосистемы Xray. Маскируется под TLS-трафик к реальному HTTPS-сайту (например cloudflare.com). DPI видит обычный TLS handshake к легитимному домену. Сложнее в настройке, но устойчивее к active probing. Active probing — это когда DPI не просто анализирует твой трафик, а сам подключается к твоему серверу и проверяет как тот отвечает. VLESS Reality отвечает как обычный HTTPS-сервер — проверка проходит.

Hysteria2 — работает поверх QUIC (UDP 443). Имитирует HTTP/3 трафик. Хорошо проходит через операторов где UDP 51820 заблокирован, но QUIC разрешён. Дополнительный бонус: QUIC имеет congestion control оптимизированный для нестабильных соединений, поэтому Hysteria2 субъективно ощущается быстрее на мобильном интернете с потерями пакетов.

Shadowsocks-2022 с плагином obfs4 — проверенная классика для ситуаций где нужна максимальная совместимость со старыми клиентами. Версия 2022 с AEAD шифрованием значительно устойчивее к детекции чем старый Shadowsocks. Clients: Android, iOS, Windows, macOS, Linux — всё есть.

AmneziaVPN (клиент) — отдельная история. Это не только AmneziaWG, это клиент который поддерживает несколько протоколов включая OpenVPN поверх Cloak, WireGuard с обфускацией и AmneziaWG. Если у тебя уже есть OpenVPN конфиг — Amnezia может обернуть его в Cloak и попробовать пробить блокировку без смены протокола. Иногда это самый быстрый путь реанимировать уже настроенный VPN.

Протокол Устойчивость к DPI Скорость Сложность настройки Клиенты
WireGuard (чистый) Низкая (блокируется) Максимальная Низкая Все ОС
AmneziaWG 2.0 Высокая Высокая Средняя Android, iOS, Linux, Windows
VLESS + Reality Очень высокая Высокая Высокая Hiddify, v2rayNG, Nekobox
Hysteria2 Высокая Высокая (QUIC) Средняя Android, iOS, Windows, Linux
Tailscale Средняя Высокая Минимальная Все ОС
OpenVPN + obfsproxy Средняя Низкая Высокая Все ОС

Мифы о VPN которые стоят тебе анонимности

За 25 лет в профессии я слышал достаточно уверенных заявлений о VPN которые были полной ерундой. Разберём самые живучие.

Миф первый: «VPN скрывает меня полностью». Нет. VPN скрывает содержимое трафика и подменяет IP. Но не скрывает сам факт использования VPN — это видно по паттернам трафика. Не скрывает тебя от браузерных fingerprint-техник: canvas, WebGL, user-agent. Не скрывает cookies и аккаунты в браузере. Если ты вошёл в Google под своим аккаунтом через VPN — Google знает кто ты. IP тут не причём.

Миф второй: «Платный VPN надёжнее бесплатного». Иногда да, иногда нет. Критерий не цена, а независимый аудит. Лучшие VPN-сервисы публикуют проверки своих систем логирования сторонними компаниями. Если провайдер говорит «мы не храним логи» но аудита нет — это просто слова. Mullvad, ProtonVPN, IVPN публикуют такие аудиты. Это не реклама, это факт.

Миф третий: «WireGuard быстрее OpenVPN значит лучше». Быстрее — да. Но в условиях блокировок скорость не главный параметр. Главный — проходит или нет. AmneziaWG немного медленнее чистого WireGuard из-за оверхеда обфускации. Это цена за прохождение через DPI. Платить стоит.

Миф четвёртый: «VPN защищает от вирусов». Нет. VPN — это шифрованный туннель для трафика. Он никак не влияет на вредоносное ПО которое уже на твоей машине. Антивирус и VPN решают разные задачи.

Миф пятый: «Если VPN работает — DNS тоже в порядке». Это мы уже разобрали выше. Нет — проверяй отдельно всегда.

Архитектура: как всё связано в рабочей схеме

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#ffffff',
    'primaryTextColor': '#1e293b',
    'primaryBorderColor': '#94a3b8',
    'lineColor': '#64748b',
    'fontSize': '14px',
    'fontFamily': 'ui-sans-serif, system-ui, sans-serif'
  },
  'flowchart': {'curve': 'linear', 'nodeSpacing': 40, 'rankSpacing': 50}
}}%%
flowchart TD
    A["Клиент: телефон/ноутбук"] --> B["AmneziaWG клиент"]
    B --> C["Обфускация: рандомные заголовки AWG 2.0"]
    C --> D["ТСПУ / DPI анализирует трафик"]
    D --> E["Сигнатура не распознана - пропуск"]
    E --> F["VPS в Финляндии/Нидерландах"]
    F --> G["AmneziaWG сервер + Unbound DNS"]
    G --> H["Выход в открытый интернет"]
    style A fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style D fill:#f8fafc,stroke:#f97316,stroke-width:2px,color:#c2410c
    style E fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d
    style F fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d
    style H fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d

Клиент отправляет трафик через AmneziaWG с рандомизированными заголовками — DPI не видит знакомой сигнатуры и пропускает пакеты. На сервере Unbound принимает DNS-запросы через туннель — они не светятся провайдеру. iptables делает NAT — трафик выходит с IP сервера.

Если нужен mesh-доступ к нескольким своим устройствам — добавляем Tailscale/Headscale поверх этой схемы. Они работают независимо: AmneziaWG для выхода наружу, Tailscale для доступа к своей инфраструктуре.

План действий: с чего начать прямо сейчас

Если после прочтения голова немного кружится от количества информации — вот конкретный порядок действий.

Шаг первый: проверь текущее состояние. Запусти dnsleaktest.com с включённым VPN. Если DNS-серверы принадлежат провайдеру — утечка. Это самая быстрая победа: исправить DNS-конфиг занимает пять минут.

Шаг второй: если обычный WireGuard перестал работать — переходи на AmneziaWG. Установка модуля ядра занимает 20-30 минут. Сгенерируй уникальные H1-H4. Это решит проблему блокировки по сигнатуре для большинства операторов.

Шаг третий: если нужен доступ к своим сервисам с телефона — поставь Tailscale. Это отдельная задача от VPN для обхода блокировок, не путай их между собой.

Шаг четвёртый: настрой мониторинг. Простой cron-скрипт который проверяет handshake и перезапускает туннель если нужно — сэкономит нервы в нужный момент.

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

FAQ

Почему VPN перестал работать после того как всё настроил?

Скорее всего провайдер обновил DPI и добавил сигнатуру твоего протокола в чёрный список. Или IP твоего VPS попал в базу блокировок. Диагностика простая: попробуй подключиться через мобильный интернет другого оператора. Если работает — проблема у конкретного провайдера, его DPI заблокировал твой протокол. Если не работает нигде — скорее всего IP VPS заблокирован. Смени IP на хостинге (обычно стоит 1-3 евро) или смени протокол на AmneziaWG с уникальными параметрами обфускации. Проверь также что порт 51820 UDP доступен с клиентской стороны командой nc -u.

Как проверить что VPN работает правильно и нет утечек?

Три проверки по порядку. Первая: открой ifconfig.me — должен показать IP твоего VPS, а не домашний. Вторая: запусти dnsleaktest.com в расширенном режиме — DNS-серверы в результате должны быть чужие, не провайдера. Третья: проверь browserleaks.com/webrtc — реальный IP не должен светиться через WebRTC. Если все три теста прошли — всё в порядке. Повторяй проверку каждый раз после смены конфигурации.

Что делать если WireGuard заблокирован провайдером?

Переходи на AmneziaWG 2.0. Это форк WireGuard с рандомизацией заголовков — DPI не видит знакомой сигнатуры. Установи серверную часть через модуль ядра, сгенерируй уникальные H1-H4 параметры командой od -A n -t d4 -N 4 /dev/urandom, скопируй их одинаково в серверный и клиентский конфиги. Клиент для Android и iOS доступен на GitHub репозитории amnezia-vpn. Если и AmneziaWG блокируют на конкретном операторе — попробуй поменять порт на 443 UDP, или переходи на VLESS Reality.

Чем Tailscale отличается от WireGuard и что выбрать?

WireGuard — это протокол, Tailscale — продукт поверх WireGuard. Tailscale добавляет автоматическое управление ключами, NAT traversal и mesh-сеть, но требует доверия к серверам Tailscale Inc. — они видят метаданные о твоих устройствах. WireGuard требует ручной настройки, зато ты полностью контролируешь инфраструктуру и никаких внешних зависимостей. Если нужен домашний NAS доступный с телефона — Tailscale быстрее настроить. Если строишь site-to-site VPN или нужен полный контроль над данными — WireGuard. Headscale даёт удобство Tailscale без зависимости от их серверов.

Безопасно ли использовать бесплатные VPN-сервисы?

По данным исследований 2025 года, более 40% бесплатных VPN-сервисов не перенаправляют DNS через туннель — это означает что провайдер видит все твои DNS-запросы. Часть сервисов логирует трафик и продаёт данные рекламодателям. Несколько крупных бесплатных VPN были пойманы на встроенной рекламе, перехвате HTTP и продаже пользовательского трафика. Если нужна реальная защита — или платный сервис с публичным независимым аудитом, или self-hosted решение на своём VPS: $5 в месяц на Hetzner закрывают задачу полностью.

Почему VPN замедляет интернет и что с этим делать?

Четыре причины замедления: шифрование (накладные расходы на процессор, обычно незначительны), MTU mismatch (пакеты фрагментируются — потеря скорости до 30%), расстояние до VPN-сервера (лишние 50+ мс пинга), и throttling со стороны провайдера (специально замедляет VPN-трафик не блокируя полностью). Решения: MTU в конфиге установить в 1380, выбирать VPS физически близко, при throttling пробовать другой порт или обфусцированный протокол.

Итог: что реально работает в 2026

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

Что изменилось за последние два года: блокировки стали умнее, но и инструменты обхода тоже. AmneziaWG 2.0 — это не патч поверх старого протокола, это переосмысление транспортного слоя с нуля. VLESS Reality закрывает проблему active probing которую не решает обфускация на уровне заголовков. Hysteria2 использует QUIC который провайдеры не могут заблокировать без того чтобы сломать половину современного веба.

Работающий стек на 2026 год: AmneziaWG 2.0 с уникальными параметрами обфускации для выхода в интернет, Tailscale или Headscale для mesh-сетки между своими устройствами, unbound или DNS-over-HTTPS для защиты DNS-трафика. Проверка через dnsleaktest.com после каждой смены конфигурации — обязательно. Это не паранойя, это базовая гигиена.

Ещё одна вещь которую стоит принять: нет решения которое работает вечно без обслуживания. Любой протокол потребует обновления через 6-12 месяцев когда DPI обучится на новых паттернах. Следи за релизами AmneziaWG на GitHub, подпишись на Хабр по теме — и будешь узнавать о изменениях раньше чем они тебя коснутся.

Не заработало?
Настроил по гайду, но что-то пошло не так — пиши в комментарии. Опиши: провайдер, ОС клиента, какой протокол, что показывает awg show на сервере и что за ошибка на клиенте. Разберёмся.
Андрей Анатольевич
Author: Андрей Анатольевич

Руководитель ИТ / Кризис-менеджер 25 лет в IT: от инженера в МегаФоне до руководителя отдела. Знаю, как выглядит бардак: нестабильные сети, устаревшая инфраструктура, конфликты в команде, раздутые сроки. Помогаю бизнесу выходить из кризиса: навожу порядок в легаси, стабилизирую то, что разваливается, выстраиваю прогнозируемые процессы. Не раз возвращал к жизни ИТ-структуры — знаю цену хаосу. 📍 Ищу проект для полной реорганизации / стабилизации. 📬 Telegram: @over_dude ✉️ mail@it-apteka.com

Оставайтесь на связи

Рецепты от IT-боли. Без воды, без рекламы, без маркетинговой шелухи.

Подписаться на IT-Аптеку →

Мы ВКонтакте

IT-Аптека — советы, новости и помощь рядом.

Вступить в группу ВКонтакте →
Поделитесь:

Похожие записи

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх