WireGuard подключён, но интернета нет: проверка маршрутов

Если WireGuard подключён, но интернета нет, считайте слово «подключён» описанием состояния интерфейса, а не доказательством работоспособности всего пути. Сначала проверьте обычное соединение, затем проследите один тестовый адрес через выбор системного маршрута, выбор пира, пересылку, преобразование адресов, обратный маршрут и DNS. Такой порядок не позволяет скрыть ошибку маршрутизации заменой DNS и удерживает диагностику от случайных правок.

Полное руководство по VPN описывает весь жизненный цикл соединения. Здесь рассматривается более узкий случай: интерфейс WireGuard активен, но заданный интернет-ресурс недоступен.

Ключевые выводы

• До любых изменений запишите результат для одного адреса по IP и по имени.
• AllowedIPs участвует и в выборе маршрута, и в выборе пира, а не служит только списком доступа.［3］
• Проверяйте IPv4, IPv6 и DNS отдельно: они могут идти разными путями.
• Для полного туннеля нужны пересылка на шлюзе, NAT или явный обратный маршрут и корректный межсетевой экран.
• Остановитесь на первом опровергнутом предположении, измените одну обратимую настройку и верните её, если результат не поменялся.

Что означает «WireGuard подключён, но интернета нет»?

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

Утилита wg показывает открытые ключи пиров, конечные точки, разрешённые адреса, время последнего рукопожатия и объёмы передачи.［2］ Читайте эти поля как разные доказательства, а не как единый зелёный индикатор.

WireGuard использует криптографическую маршрутизацию (cryptokey routing): адрес назначения помогает выбрать пир для исходящего трафика, а входящий пир может заявлять только назначенные ему исходные адреса.［3］ Помощник wg-quick также способен создавать системные маршруты из AllowedIPs, включая специальную обработку маршрута по умолчанию.［1］ Поэтому маршрут может отсутствовать, уступать более узкому маршруту, находиться в другой таблице политики или относиться не к тому пиру, хотя интерфейс существует.

Наблюдение	Что подтверждено	Что ещё не подтверждено
Интерфейс активен	Локальная настройка интерфейса завершена	Аутентификация пира и маршрутизация
Время рукопожатия обновляется	Пиры недавно аутентифицировались	Тестовый пакет использует этот пир
Растёт только TX	Локальная сторона отправляет шифрованные пакеты	Приём, пересылка и возврат ответа
Растёт только RX	Пир может доставить часть трафика	Текущий запрос выбрал правильный маршрут
Растут TX и RX	Шифрованный трафик идёт в обе стороны	DNS и конечное приложение работают
IP работает, имя нет	Работает хотя бы один IP-путь	Доступен и правильно выбран DNS

Семь шагов проверки маршрутизации

Шаг 1. Зафиксируйте исходное состояние обычной сети

Приостановите туннель поддерживаемым способом и проверьте ту же физическую сеть. Запишите, пройдена ли страница авторизации, доступен ли один известный IPv4-адрес и один IPv6-адрес, разрешается ли стабильное имя и правильно ли установлено системное время. Если сеть не работает без туннеля, сначала исправьте или смените её.

Выберите ограниченные проверки. Используйте адрес, который вы вправе тестировать, и запишите его IP, протокол и время. Отсутствие ответа на ping не означает отказ всего трафика: веб-запрос, DNS-запрос и запрос маршрута отвечают на разные вопросы. Методика ограниченной проверки VPN помогает не смешивать эти результаты.

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

Остановитесь, если обычная сеть уже неисправна или у вас нет разрешения изучать и менять устройство либо шлюз. Нельзя компенсировать внешнюю аварию ослаблением туннеля.

Шаг 2. Убедитесь, что адрес действительно направляется в туннель

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

При полном туннеле действующие маршруты должны охватывать целевые IPv4-адреса и, если это обещает конфигурация, IPv6. При раздельной маршрутизации в WireGuard должны попадать только заявленные частные или служебные префиксы. Если обычный интернет намеренно оставлен вне туннеля, неизменившийся публичный IP может быть нормой; это различие разобрано в руководстве о неизменившемся IP.

Сопоставьте маршрут с AllowedIPs выбранного пира. Отдельное руководство по AllowedIPs объясняет пересечение префиксов и выбор наиболее узкого. На этом этапе нужен практический ответ: выбирает ли этот адрес ровно один ожидаемый пир либо побеждает другой пир, локальная подсеть, более точный маршрут, правило политики или исключение?

wg-quick обычно выводит маршруты из разрешённых адресов, однако маршрут по умолчанию может быть реализован через маршрутизацию по политикам (policy routing) и метки межсетевого экрана, а не очевидной заменой записи в основной таблице.［1］ Изучайте фактическое состояние платформы.

Остановитесь, когда маршрут идёт мимо нужного туннеля или выбирает неверный пир. Исправьте только эту привязку поддерживаемым способом, повторите тест один раз и отмените правку, если выбор пути не изменился.

Шаг 3. Отделите DNS от маршрута пакета

Сначала обратитесь к записанному числовому IP. Затем опросите настроенный резолвер и по отдельности проверьте все возвращённые адреса IPv4 и IPv6. Если числовой адрес работает, а имя нет, главным подозреваемым становится не зашифрованный канал, а адрес резолвера, его достижимость, поисковые суффиксы, устаревший кэш либо выбор DNS внутри или снаружи туннеля.

Резолвер может быть доступен по IPv4, хотя приложение предпочитает недоступный результат IPv6. Настройка из файла также может быть перекрыта правилами для домена или интерфейса. Записывайте, какой резолвер система реально выбрала для данного имени.

Не заменяйте DNS в управляемом профиле произвольным публичным сервисом. Это может раскрыть запросы, нарушить внутренние имена и политику сети. После разрешённого временного сравнения восстановите прежнее значение.

Шаг 4. Проверяйте IPv4 и IPv6 как разные пути

Для явных адресов IPv4 и IPv6 отдельно запишите маршрут, исходный адрес, изменения TX/RX и результат. Частая половинчатая ситуация: IPv4 идёт через WireGuard, а IPv6 остаётся на физическом интерфейсе, не имеет маршрута или приходит на шлюз без пересылки IPv6. Возможна и обратная картина.

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

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

Шаг 5. Проверьте пересылку и обработку исходного адреса на шлюзе

Даже когда клиент отправил пакет в WireGuard, шлюз должен переслать его в интернет. Подтвердите пересылку для нужного семейства адресов и направления интерфейсов. Затем определите предусмотренный проектом механизм возврата: исходящий NAT, маршрутизируемый клиентский префикс или иной явный путь.

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

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

Шаг 6. Проследите обратный путь и состояние межсетевого экрана

Односторонние счётчики хорошо локализуют границу. Если TX клиента растёт, а RX WireGuard на сервере нет, изучайте внешний путь, endpoint и привязку пира, а не NAT шлюза. Если серверный RX растёт, но пакет не появляется на интернет-интерфейсе, проверяйте пересылку и межсетевой экран. Если пакет вышел, но ответ не пришёл, проверяйте службу назначения, вышестоящий маршрут, состояние трансляции и фильтрацию. Если ответ дошёл до сервера, но RX клиента не изменился, смотрите выбор обратного пира, разрешённый исходный префикс и межсетевой экран туннеля.

Межсетевой экран с отслеживанием состояния способен пропустить рукопожатие и отклонить пересылаемый трафик, поскольку он проходит другую цепочку, зону, namespace или направление. Сравнивайте узкие счётчики правил, относящиеся к тесту. Не отключайте межсетевой экран целиком: это меняет границу риска и уничтожает сведения о конкретном правиле.

Локальный межсетевой экран тоже может отбросить пакет после его возврата через WireGuard. Сопоставьте интерфейсные счётчики с разрешённым локальным наблюдением и сразу удалите временное правило.

Шаг 7. Повторите полный путь и отмените эксперименты

После исправления первой доказанной неисправности повторите тот же запрос по IP, DNS-запрос и действие приложения. Ещё раз подтвердите маршрут и исходный адрес, сравнив новые приращения TX/RX, а не накопленные объёмы. Проверьте второе семейство адресов, если оно входит в условия.

Верните все временные изменения MTU, маршрутов, DNS, межсетевого экрана и правил политики, которые не объяснили результат. Сохраняйте успешную правку только в поддерживаемой постоянной конфигурации и лишь после понимания её действия. Если маленькие запросы работают, а крупные передачи останавливаются, перейдите к диагностике MTU WireGuard, а не меняйте маршруты снова.

Поможет ли управляемое VPN-приложение локализовать сбой?

Управляемый клиент — быстрый контрольный тест для первого шага этого чек-листа. Установите AethoVPN на то же устройство, подключитесь с включённым глобальным режимом и откройте заведомо рабочий сайт: если он загружается, а ваш собственный пир WireGuard показывает подключение без интернета, сетевой стек устройства и сеть доступа в порядке, а сбой находится в маршрутах, DNS, пересылке или NAT вашего пира. Если не работает ни то ни другое, сначала проверьте локальную сеть или межсетевой экран, а не пир. Приложение документирует состояния подключения и переключатель глобального режима, а не исходные профили WireGuard, таблицы пиров или правила шлюза, поэтому более глубокие шаги остаются за тем, кто управляет вашим сервером. Скачайте клиент для своей платформы, чтобы провести контрольный тест.

Итоги

• Докажите работоспособность обычной сети до исследования туннеля.
• Запросите действующий маршрут для одного точного адреса и сопоставьте его с пиром.
• Раздельно проверяйте имена, числовые адреса, IPv4 и IPv6.
• На шлюзе подтвердите пересылку и либо корректный NAT, либо явный обратный маршрут.
• Используйте направленные счётчики и не отключайте общие средства защиты.
• Повторяйте один и тот же тест и отменяйте все эксперименты, не изменившие доказательства.

Часто задаваемые вопросы (FAQ)

Может ли WireGuard показывать подключение без свежего рукопожатия?

Да. Некоторые приложения считают подключением активный интерфейс и загруженную конфигурацию. Время последнего рукопожатия и новые приращения передачи нужно проверять отдельно.

Гарантирует ли 0.0.0.0/0 в AllowedIPs доступ в интернет?

Нет. Эта запись делает пир кандидатом для всех IPv4-адресов и может создать маршрут, но всё ещё нужны пересылка, межсетевой экран, обработка исходного адреса, обратный путь и DNS.

Почему IP работает, а имя сайта не открывается?

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

Почему IPv4 работает, а IPv6 нет?

У семейств независимые маршруты, разрешённые префиксы, пересылка, правила межсетевого экрана и обратные пути. Успех одной проверки не доказывает работоспособность другой.

Всегда ли серверу WireGuard нужен NAT?

Нет. NAT часто обеспечивает возврат к частным IPv4-адресам клиентов. Маршрутизируемая схема работает без него, когда вышестоящие сети знают путь к клиентскому префиксу.

Следует ли отключить межсетевой экран для проверки маршрутизации?

Нет. Используйте запросы маршрутов, счётчики интерфейсов и узких правил. Полное отключение защиты расширяет риск и лишает вас сведений о том, какое правило повлияло на пакет.

Когда следует прекратить менять маршруты?

Прекратите, когда одна и та же проба доказанно входит в нужный пир и возвращается. Если не работают только имена, переходите к DNS; если только крупные пакеты — к MTU; если аутентификация не актуальна — диагностируйте рукопожатие.

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

Источники:

1. WireGuard Tools, "wg-quick(8)": https://git.zx2c4.com/wireguard-tools/tree/src/man/wg-quick.8
2. WireGuard Tools, "wg(8)": https://git.zx2c4.com/wireguard-tools/tree/src/man/wg.8
3. WireGuard, "WireGuard: Next Generation Kernel Network Tunnel": https://www.wireguard.com/papers/wireguard.pdf

Sources checked 12 сентября 2026 г.

---

Рекомендуемые статьи:

• Изучить полный путь VPN-соединения
• Разобраться с WireGuard AllowedIPs
• Понять, почему публичный IP не изменился
• Проверить VPN ограниченным набором тестов