WireGuard: нет интернета через VPN — причины и решение

MAATRIX

Туннель поднялся, wg show показывает handshake, а интернета нет: WireGuard нет интернета через VPN. Классическая ситуация — соединение установлено, но трафик клиента не выходит в сеть. Причина почти всегда на стороне сервера: не включён форвардинг, не настроен NAT-маскарадинг, неверный AllowedIPs или не работает DNS. Разберём по порядку, как заставить трафик пойти.

Первое действие: определите, где обрывается трафик

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

ping -c2 10.0.0.1
ping -c2 8.8.8.8
ping -c2 google.com

Если не пингуется даже внутренний адрес сервера (10.0.0.1) — проблема в самом туннеле или AllowedIPs. Если внутренний адрес доступен, а внешний IP 8.8.8.8 — нет, то трафик доходит до сервера, но не выходит наружу: не хватает форвардинга или NAT. Если 8.8.8.8 пингуется, а имена не резолвятся — сеть есть, сломан DNS. Эти три точки обрыва — туннель, выход наружу, DNS — и есть три ветки диагностики. Определив свою, вы сразу знаете причину и не тратите время на неверные правки.

Причина 1: не включён форвардинг пакетов

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

sysctl net.ipv4.ip_forward

Если значение 0 — форвардинг отключён, и это ровно ваша проблема. Включите его немедленно и закрепите, чтобы он сохранялся после перезагрузки:

sysctl -w net.ipv4.ip_forward=1
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf

Это одна из двух ключевых серверных настроек для работы VPN-шлюза (вторая — NAT, ниже). Без форвардинга сервер не выполняет свою главную роль — не передаёт чужой трафик дальше. Очень частая причина «туннель есть, интернета нет» — именно забытый форвардинг. После включения проверьте пинг наружу снова. Если внешний IP пошёл пинговаться — половина дела сделана; если нет, переходите к NAT.

Причина 2: не настроен NAT-маскарадинг

Даже с форвардингом трафик не вернётся к клиенту, если на сервере не настроен NAT (маскарадинг). Пакеты клиента с адресами внутренней подсети VPN уходят в интернет, но ответы не знают, как вернуться, — их нужно «замаскировать» под адрес сервера. Правило маскарадинга обычно прописывают в PostUp/PostDown конфига WireGuard или добавляют вручную:

iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -j MASQUERADE

Здесь eth0 — внешний интерфейс сервера (уточните его имя через ip route), 10.0.0.0/24 — подсеть VPN. Правильный способ — добавить это правило в секцию [Interface] конфига как PostUp, а обратное удаление — в PostDown, чтобы оно ставилось при поднятии туннеля и убиралось при опускании. Без маскарадинга вы увидите ровно симптом «до сервера доходит, наружу не идёт» даже при включённом форвардинге. Форвардинг и NAT работают в паре: первый разрешает пересылку, второй обеспечивает возврат ответов. Настроив оба, вы получаете рабочий выход в интернет через VPN.

Причина 3: неверный AllowedIPs на клиенте

AllowedIPs в конфиге клиента определяет, какой трафик направляется в туннель. Если он задан слишком узко, через VPN пойдёт только часть трафика, и «интернета» словно нет, хотя туннель работает. Чтобы весь трафик клиента шёл через VPN (полный туннель), в секции [Peer] клиента должно быть:

AllowedIPs = 0.0.0.0/0

Значение 0.0.0.0/0 означает «весь трафик — в туннель». Если там стоит только внутренняя подсеть (например, 10.0.0.0/24), то в туннель уйдёт лишь трафик до самого сервера, а интернет пойдёт напрямую — и при заблокированном напрямую сервисе вы решите, что VPN не работает. Для доступа ко всему интернету через сервер нужен именно полный туннель. И наоборот: если вам нужен раздельный туннель (только часть трафика через VPN), AllowedIPs задаёт нужные подсети осознанно. Понимание роли AllowedIPs снимает частую путаницу «туннель поднят, а сайты открываются мимо VPN».

Причина 4: не работает DNS через туннель

Если по IP всё пингуется (8.8.8.8 доступен), а сайты по именам не открываются — проблема в DNS. При полном туннеле клиент должен использовать DNS-сервер, доступный через VPN, иначе разрешение имён ломается или утекает мимо туннеля. Задайте DNS в секции [Interface] конфига клиента:

DNS = 1.1.1.1

Тогда клиент при подключении будет использовать указанный DNS. Без этой строки клиент может пытаться ходить к DNS, недоступному через туннель, и имена перестанут резолвиться, хотя по IP связь есть. Убедитесь также, что выбранный DNS-сервер действительно доступен с сервера (он же маршрутизирует запрос). Рабочий DNS через туннель — финальный штрих: с ним у клиента и связь наружу, и разрешение имён. Симптом «по IP работает, по имени нет» почти всегда лечится именно строкой DNS в конфиге клиента.

Как проверить, что VPN полностью работает

После правок проверьте всю цепочку с клиента, подключённого к VPN: и внешний IP (через какой адрес вы выходите в интернет), и резолв имён. Быстрый тест:

curl -s https://api.ipify.org; echo
curl -sI https://google.com | head -n1

Если ipify вернул IP вашего сервера (а не вашего домашнего провайдера) — трафик реально идёт через VPN, форвардинг и NAT работают. Если curl к сайту по имени вернул HTTP/2 200 — DNS тоже в порядке. Совпадение внешнего IP с адресом сервера — главное подтверждение, что полный туннель работает как задумано. Если IP всё ещё ваш домашний — трафик идёт мимо туннеля, вернитесь к AllowedIPs. Эта проверка однозначно показывает, что VPN не просто «поднят», а действительно пропускает и маршрутизирует ваш интернет.

Профилактика: стабильный выход в интернет через VPN

Чтобы VPN работал сразу и надёжно, запомните два серверных столпа: включённый форвардинг (ip_forward=1, сохранённый в sysctl) и правило NAT-маскарадинга, привязанное к поднятию туннеля через PostUp/PostDown. Эти двое обеспечивают выход трафика наружу и его возврат. На стороне клиента для полного доступа держите AllowedIPs = 0.0.0.0/0 и заданный DNS, доступный через туннель. Прописав всё это один раз правильно, вы получаете VPN, который стабильно выходит в интернет.

Проверяйте, что имя внешнего интерфейса в правиле NAT совпадает с реальным (ip route | grep default), — при переносе на другой сервер оно может отличаться, и старое правило перестанет работать. Берите под VPN сервер с чистым IP в нужной локации: от качества IP зависит доступ к сервисам и частота капчи. Свой VPS с полным контролем над ядром, форвардингом и NAT — правильная основа для WireGuard. С настроенными форвардингом, NAT, полным туннелем и DNS «нет интернета через VPN» превращается в стабильно работающий канал.

Частые вопросы