Как я починил интернет на сервере после настройки VPN и ufw

Проблема: сервер жив, но интернета нет

Представьте: у вас есть VPS-сервер. На нём крутится сайт, работает SSH, всё замечательно. Вы решаете поднять VPN (WireGuard, чтобы смотреть YouTube или для доступа к сервисам) — настраиваете, проверяете, всё работает.

Но потом замечаете: формы на сайте перестали отправлять письма. Лезете в логи — PHPMailer не может подключиться к SMTP. Проверяете вручную:

nslookup pochta.logoakademia.ru → timed out
ping 8.8.8.8 → 100% packet loss
curl https://google.com → Resolving timed out

Сервер как будто в изоляции: пинг до шлюза есть, а дальше — тишина. Что сломалось?

Диагностика: от DNS до маршрутов

Первое, что приходит в голову — DNS. Может, /etc/resolv.conf слетел? Проверяем — нет, там 8.8.8.8. Пробуем nslookup — таймаут. Значит, не DNS-сервер виноват, а сетевой стек.

Проверяем маршруты:

ip route show
default via 91.199.160.254 dev ens3 onlink

Флаг onlink — красный флаг. Он говорит ядру: «не проверяй, в одной ли ты подсети со шлюзом». В 99% случаев он не нужен — и может ломать маршрутизацию. Убираем:

sudo ip route replace default via 91.199.160.254 dev ens3

Проверяем снова — всё равно не работает. Значит, проблема глубже.

Фаервол? ufw status говорит — нет!

Смотрим настройки ufw:

Default: deny (incoming), allow (outgoing), deny (routed)

Исходящий трафик разрешён! Значит, ufw не блокирует ping, DNS или SMTP. Проверяем правила ICMP — разрешены. Проверяем логи — тишина. Фаервол не виноват.

Но… при включении ufw — интернет появляется? Нет. Значит, дело не в фильтрации, а в NAT.

Прорыв: проблема в MASQUERADE

Лезем в /etc/ufw/before.rules. Видим:

*nat
-A POSTROUTING -s 10.0.0.0/24 -o ens3 -j MASQUERADE
COMMIT

Это правило маскарадит (подменяет исходный IP) только для клиентов VPN (10.0.0.0/24). А что насчёт самого сервера с IP 91.199.160.238? Для него — никакого MASQUERADE!

Провайдер видит пакет с исходным IP сервера — но так как сервер не находится «за NAT провайдера» в его логике — пакеты отбрасываются. Особенно часто такое бывает у хостингов с CGNAT или строгим egress-filtering.

Решение — добавить универсальное правило:

-A POSTROUTING -o ens3 -j MASQUERADE

Теперь ВЕСЬ трафик, уходящий через ens3, будет маскарадиться — и сервер, и VPN-клиенты.

Ошибка конфига и финальная победа

После добавления правила — ufw enable падает с ошибкой:

Bad argument '*nat'

В чём дело? Оказывается, секция *nat была вставлена ВНУТРИ секции *filter. А iptables так не умеет. Правильная структура:

*filter
... правила ...
COMMIT

*nat
... правила NAT ...
COMMIT

Исправляем структуру → перезапускаем ufw → и...

ping ya.ru → 64 bytes from ya.ru: icmp_seq=1 ttl=56 time=43ms
nslookup pochta.logoakademia.ru → Address: 185.9.145.131

🎉 Интернет заработал! Форма на сайте снова отправляет письма.

Выводы и советы

• onlink — используйте только если точно знаете, зачем он нужен. В 99% случаев — не нужен.
• ufw — если исходящий трафик разрешён, а интернета нет — смотрите в сторону NAT/MASQUERADE.
• WireGuard — если не хотите, чтобы VPN ломал интернет сервера, добавьте в wg0.conf:

  Table = off

  или настройте policy-based routing.
• Диагностика — всегда проверяйте:
  • ping ШЛЮЗ — есть ли связь с роутером?
  • nslookup — работает ли DNS?
  • curl -I — работает ли HTTP/HTTPS?
  • ip route show — правильный ли маршрут?
  • iptables -t nat -L -n -v — применяются ли правила NAT?

Иногда проблема не в том, что что-то запрещено — а в том, что чего-то не хватает. В нашем случае — не хватало одной строчки MASQUERADE.