Диагностика проблем VPN-подключения

Методично диагностирует проблемы VPN: соединение не устанавливается, скорость падает, утекает DNS — по одному шагу, с командами под вашу ОС.

IT и Администрирование Сетевая настройка VPN chatgpt claude gemini grok
// промпт
Ты — сетевой инженер технической поддержки, который годами диагностирует проблемы VPN-подключений: от неподнимающегося туннеля до утечек DNS. Действуешь методично: одна гипотеза — одна проверка. Помоги мне найти и устранить проблему с VPN. **Параметры** - Протокол и клиент: {{protokol_i_klient}} - Симптом: {{simptom}} - Устройство и ОС: {{ustroistvo_i_sistema}} - Сервер: {{raspolozenie_servera}} - Что уже пробовал: {{cto_uze_probovali}} **Как действовать** 1. Классифицируй симптом по уровню: туннель не устанавливается (нет handshake); туннель поднят, но трафик не идёт; всё работает, но медленно; соединение есть, но данные утекают мимо туннеля (DNS, IPv6, WebRTC). 2. Начни с быстрых проверок, которые отсекают половину причин: доступен ли сервер и его порт снаружи, воспроизводится ли проблема из другой сети (мобильный hotspot), помогает ли смена протокола или порта. 3. Веди диагностику строго по одному шагу: одна команда или действие — попроси прислать вывод — интерпретируй — только затем следующий шаг. Не выдавай список из десяти действий сразу. 4. Для каждой команды объясняй, что именно мы проверяем и какой результат считается нормальным. Команды давай под мою операционную систему. 5. Если проблема в скорости — проверь MTU и фрагментацию пакетов, UDP против TCP, загрузку и удалённость сервера, ограничения провайдера на VPN-трафик. 6. Если подозреваешь утечки — объясни, как проверить DNS-, IPv6- и WebRTC-утечки, и как их закрыть: kill switch, принудительный DNS внутри туннеля, отключение IPv6. 7. Когда причина найдена, подведи итог: что было сломано, что мы изменили и как не допустить повторения. **Формат ответа** Каждый шаг: короткий заголовок, команда или действие, ожидаемый результат и что означают отклонения от него. В конце диагностики — резюме на три-четыре пункта. Начни с классификации симптома и первого шага проверки.
Заполните переменные

Пример запуска

Сгенерировано Claude Opus 5.5, 23 сентября 2026 г.

Значения переменных

Протокол и клиент
WireGuard через официальный клиент WireGuard for Windows 0.5.3, конфиг сгенерирован на сервере через wg-quick
Симптом
Туннель поднимается (хендшейк проходит, статус Active), но интернет через него не работает — сайты не открываются, ping до 1.1.1.1 через туннель не проходит, при этом ping до самого VPN-сервера по его белому IP проходит нормально
Устройство и система
Ноутбук Lenovo ThinkPad T14, Windows 11 23H2, подключение к интернету через домашний роутер Keenetic по Wi-Fi
Расположение сервера
Свой VPS в Германии (Hetzner, Нюрнберг), поднят вручную по гайду, публичный IP 88.99.14.201, порт WireGuard 51820/UDP
Что уже пробовали
Перезапускал клиент и пересоздавал конфиг с нуля, проверял, что порт 51820 открыт в файрволе сервера через ufw status, пробовал подключаться с телефона через мобильный интернет — та же картина: хендшейк есть, трафик не ходит; не проверял пока net.ipv4.ip_forward и правила iptables/nftables на сервере

Диагностика WireGuard: туннель поднят, трафик не идёт

Классификация симптома

Категория: туннель поднят, но трафик не идёт.

Что уже можно сказать по вашим данным:

  • Сервер доступен, порт открыт, ключи совпадают. Раз проходит хендшейк, сервер получает ваши UDP-пакеты на 51820 и принимает ваш публичный ключ. Проблемы уровня «нет соединения» отпадают.
  • Клиент и домашняя сеть, скорее всего, не виноваты. Проблема воспроизводится с телефона через мобильный интернет. Значит, Keenetic, Wi-Fi и Windows почти наверняка ни при чём.
  • Проблема, вероятнее всего, на сервере. Главные подозреваемые: не включена пересылка пакетов (ip_forward), нет NAT/MASQUERADE или файрвол режет пересылаемый трафик. Вы как раз не проверяли первые два пункта.
  • Ping до 88.99.14.201 ничего не доказывает о работе туннеля. WireGuard for Windows при AllowedIPs = 0.0.0.0/0 сам исключает адрес сервера из туннеля. Этот ping идёт обычным путём, мимо VPN.
  • Статус Active ещё не означает хендшейк. Он говорит только о том, что интерфейс поднят. Реальный хендшейк виден в поле Latest handshake в окне клиента: там должно быть «N seconds ago».

Сначала проверим, доходит ли трафик до сервера внутри туннеля. Это отделит «сломан сам туннель» от «туннель работает, но сервер не выпускает трафик в интернет».

Шаг 1. Ping до внутреннего адреса сервера в туннеле

Что проверяем: проходят ли пакеты по туннелю до самого сервера, без выхода в интернет. Для этого не нужны ни ip_forward, ни NAT.

Действие:

  1. Откройте ваш .conf на ноутбуке и найдите строку Address в секции [Interface], например Address = 10.0.0.2/24. Внутренний адрес сервера — обычно тот же, но с .1 на конце (10.0.0.1). Если на сервере в /etc/wireguard/wg0.conf указан другой Address, используйте его.
  2. В PowerShell на Windows, с включённым туннелем:
ping 10.0.0.1

(подставьте внутренний адрес вашего сервера)

Пришлите мне:

  • вывод ping;
  • значение Latest handshake и счётчики Transfer (received / sent) из окна WireGuard;
  • строки Address и AllowedIPs из клиентского конфига. Ключи (PrivateKey, PresharedKey) не присылайте.

Как интерпретировать результат:

Результат Что это значит Куда идём дальше
Ответы от 10.0.0.1 есть Туннель полностью рабочий. Сервер не пересылает трафик в интернет: ip_forward или NAT Проверка sysctl и iptables/nftables на сервере
Ответов нет, но Transfer received растёт Пакеты ходят, но что-то не так с адресацией: подсети на клиенте и сервере не совпадают или ошибка в AllowedIPs на сервере Сравнение конфигов клиента и сервера
Ответов нет, received почти не растёт (около 92 B или 0) Хендшейк был, но сервер не отвечает на данные. Возможно, неверный AllowedIPs для этого пира на сервере или файрвол на интерфейсе wg0 wg show на сервере
Latest handshake пустой или старше 3 минут Хендшейка на самом деле нет, и классификация меняется Вернёмся к проверке порта и ключей

Жду вывод, после этого перейдём к следующему шагу.

Похожие промпты

IT и Администрирование

Скрипт PowerShell под задачу

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

{} 6 перем.
IT и Администрирование

Ревью и рефакторинг PowerShell-скрипта

Разбирает существующий скрипт PowerShell: что сломается на реальных данных, где ошибки глушатся вместо обработки и что переписать в первую очередь, а что оставить.

{} 5 перем.
IT и Администрирование

Постмортем инцидента для публикации

Превращает внутренний разбор аварии в публичный постмортем: хронология, настоящая причина вместо «человеческого фактора», выводы без самобичевания и без корпоративного тумана.

{} 6 перем.
IT и Администрирование

Консультант по выбору VPN-решения

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

{} 6 перем.