OpenVPN подключается, но нет доступа к сети

MAATRIX

В логе клиента строка Initialization Sequence Completed — вроде бы всё получилось. Но браузер ничего не грузит, пинг до интернета не идёт, будто VPN и не подключён. Это не сбой туннеля: соединение установлено, сертификаты приняты, клиент получил адрес. Ломается то, что происходит с трафиком дальше, — и чинится это быстро, если идти по порядку, а не наугад.

Дерево диагностики: за полминуты понять, где сломано

Не начинайте с правки конфигов. Сначала определите ветку — дальше вы прочитаете один-два раздела вместо всех восьми.

Пингуется внутренний адрес сервера (обычно 10.8.0.1)?
├─ НЕТ → пакеты не доходят до сервера вообще.
│        Смотрите: права и маршруты клиента (8), поднялся ли TUN,
│        фаервол сервера на цепочке INPUT.
└─ ДА → туннель живой.
   Пингуется внешний IP (1.1.1.1)?
   ├─ НЕТ → пакеты уходят, но не выпускаются или не возвращаются.
   │        Смотрите: ip_forward (1), NAT (2), redirect-gateway (3),
   │        FORWARD и фильтр хостера (5), конфликт подсетей (6).
   └─ ДА → маршрутизация работает.
      Резолвится домен (nslookup google.com)?
      ├─ НЕТ → имена не переводятся в адреса. Смотрите: DNS (4).
      └─ ДА → имена работают.
         Сайты открываются целиком, без зависаний?
         ├─ НЕТ, лёгкие открываются, тяжёлые висят → MTU (7).
         └─ ДА → готово.

Верхняя ветка — единственная, где остальные разделы бесполезны: там ломается сам транспорт. Если туннель не поднимается устойчиво, такие отказы разобраны в статье про частые ошибки OpenVPN на сервере.

Словарь: что означают слова из конфигов

Проверка по уровням: четыре шага строго по порядку

Подключитесь к VPN и выполняйте команды по очереди. На Windows вместо ping -c 4 пишите ping -n 4. Не перескакивайте: следующий уровень имеет смысл только при пройденном предыдущем.

ping -c 4 10.8.0.1        # уровень 1: сервер внутри туннеля
ping -c 4 1.1.1.1         # уровень 2: внешний IP без участия DNS
nslookup google.com       # уровень 3: перевод имени в адрес
curl -sI https://ya.ru    # уровень 4: реальный HTTPS-запрос

Уровень 1. 10.8.0.1 обычно и есть сервер внутри туннеля; своё значение смотрите в строке server конфига — сервер берёт первый адрес подсети. Провал означает, что пакеты до сервера не доходят: нет маршрута в VPN-подсеть, не поднялся TUN или фаервол режет входящее с tun0. Разделы про NAT и forwarding здесь бесполезны.

Уровень 2. DNS не участвует, поэтому провал — чистая маршрутизация: сервер не пересылает чужие пакеты, не подменяет обратный адрес, фильтр режет транзит либо клиент вообще не отправил пакет в туннель.

Уровень 3. Уровень 2 прошёл, а nslookup молчит — сломан только DNS. Смотрите строку Server: в его выводе: адрес вида 192.168.х.х значит, что имена спрашиваются в обход туннеля. Это и причина неработающих сайтов, и утечка данных — как её закрыть, разобрано в статье про проверку DNS-утечек через VPN.

Уровень 4. Имена резолвятся, но curl виснет, лёгкие сайты открываются, а тяжёлые нет — это почти всегда MTU, а не маршруты. Если всё работает, но медленно и с обрывами, диагностика другая — в материале про медленную работу VPN по шагам.

Таблица: симптом → причина → что делать

Причина 1: на сервере выключен IP forwarding

По умолчанию система не пересылает чужие пакеты — она принимает только адресованное ей самой. Это защита ядра, её включают там, где машина работает маршрутизатором. Без неё сервер получает от клиента пакет «отправь меня на 1.1.1.1» и просто выбрасывает его.

sysctl net.ipv4.ip_forward         # 0 — выключено, 1 — включено
sysctl -w net.ipv4.ip_forward=1    # включить до перезагрузки
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
sysctl -p                          # закрепить и применить

Тонкость: на части дистрибутивов параметр дублируется в файлах /etc/sysctl.d/, и значение оттуда перебивает ваше. Если после sysctl -p вывод по-прежнему нулевой, ищите конфликт: grep -r ip_forward /etc/sysctl.conf /etc/sysctl.d/.

Причина 2: нет NAT — сервер не подменяет обратный адрес

Даже с включённым forwarding пакет от клиента с адресом 10.8.0.2 уходит наружу, но ответ не знает, куда возвращаться: такого адреса в открытом интернете нет. Сервер обязан подменить исходный адрес на свой публичный — это NAT, а конкретное правило называется маскарадингом.

Сначала узнайте имя внешнего интерфейса (eth0, ens3, venet0): оно стоит после слова dev в выводе ip route | grep default. Дальше подставьте это имя и свою подсеть VPN из строки server:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
apt install -y iptables-persistent && netfilter-persistent save
iptables -t nat -L POSTROUTING -n -v

Вторая строка сохраняет правило между перезагрузками, третья показывает, ловит ли оно пакеты: пока клиент что-то грузит, счётчик pkts должен расти. Нулевой счётчик при активном трафике означает, что правило написано не для того интерфейса или не для той подсети. На системах с nftables правило видно и в nft list ruleset — если его нет нигде, вы редактируете не тот бэкенд. Отдельная история — сервер за внешним NAT провайдера, она разобрана в статье про VPN-сервер за NAT и проброс портов.

Причина 3: сервер не отдаёт клиенту маршрут по умолчанию

Даже при рабочих forwarding и NAT интернета не будет, если клиент не отправляет обычный трафик в туннель. Решает это сервер: без соответствующей команды через VPN пойдёт только трафик до его подсети, а остальной интернет клиент отправит своим обычным каналом. Признак характерный: интернет работает нормально, всё открывается, но внешний IP остался домашним — это видно по curl -s https://api.ipify.org, подробнее в материале про проверку IP и страны после туннеля. В server.conf должна быть строка:

push "redirect-gateway def1 bypass-dhcp"

def1 — не опечатка и не «версия 1»: он добавляет два более специфичных маршрута вместо замены основного шлюза целиком, поэтому связь с самим сервером не рвётся в момент переключения. bypass-dhcp снимает конфликт с получением адреса по DHCP на части клиентов.

После правки перезапустите службу — запущенный процесс конфиг на лету не перечитывает: systemctl restart openvpn-server@server. Имя после @ совпадает с именем файла конфигурации без расширения. Учтите ещё: строка route-nopull у клиента заставляет его игнорировать любые пушнутые маршруты — так делают намеренно при раздельном туннелировании, и «нет интернета через VPN» там ожидаемое поведение.

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

Сценарий узнаваемый: ping 1.1.1.1 проходит, а имя сайта не открывается. Если сервер не подсказал клиенту, какой DNS использовать, тот спрашивает домашний резолвер в обход туннеля либо не имеет рабочего DNS для этой сети вовсе.

push "dhcp-option DNS 1.1.1.1"
push "dhcp-option DNS 8.8.8.8"

После правки — перезапуск службы и обязательное переподключение клиента: настройки DNS он получает только при установке нового соединения. На Windows система может параллельно опрашивать провайдерский резолвер; чтобы этого не было, в конфиг клиента добавляют block-outside-dns.

Второй источник той же проблемы — Linux-десктоп с systemd-resolved: клиент получает DNS от сервера, но не умеет применить его без вспомогательного скрипта. Признак — прежние адреса в выводе resolvectl status. Лечится строками в конфиге клиента:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

Причина 5: фаервол сервера или фильтр хостера режет транзит

Фаервол может пропускать входящие подключения к OpenVPN на порт 1194 и при этом резать транзитный трафик — тот, что идёт не серверу, а через сервер. Это отдельная цепочка FORWARD, и её легко забыть, если фаервол настраивали до появления VPN.

Для ufw смотрите ufw status verbose: строка Default: deny (forward) и есть блокировка. Правится в /etc/default/ufw — DEFAULT_FORWARD_POLICY="DROP" меняется на "ACCEPT", затем ufw disable && ufw enable. Тонкость ufw: правило NAT нужно писать в /etc/ufw/before.rules, секция *nat, — голую команду iptables он перезапишет. Для чистого iptables:

iptables -L FORWARD -n -v --line-numbers
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -j ACCEPT

Политика DROP в шапке цепочки при отсутствии разрешающих правил для tun0 — типичная причина «форвардинг включён, NAT настроен, а всё равно ничего не идёт». Сохраните правила тем же netfilter-persistent save.

Третий слой — фильтр вне операционной системы: security group в облачной панели или ACL хостера. Он срабатывает раньше, чем ядро увидит пакет, поэтому изнутри не виден совсем: правила пусты, счётчики нулевые, трафика нет. Признак — сам сервер в интернет ходит, а транзит клиентов не идёт. У Windows-клиентов бывает зеркальный случай: встроенный фаервол режет трафик на новом адаптере, сочтя сеть «Общедоступной» — порты Windows Firewall для VPN.

Причина 6: конфликт подсетей

Самая неочевидная из частых причин. Подсеть 10.8.0.0/24 по умолчанию с домашними сетями не пересекается, но если её сменили на 192.168.0.0/24 или 192.168.1.0/24 — а именно такие диапазоны раздаёт большинство домашних роутеров — один и тот же адрес принадлежит одновременно локальной сети и туннелю. Система выбирает какой-то один маршрут, и часть трафика уходит не туда.

Симптомы сбивают с толку: интернет работает частично, принтер и NAS исчезли, у одного пользователя всё хорошо, а у другого нет, и вся разница — в модели роутера. Сравните свою локальную подсеть с VPN-подсетью:

ip route      # Linux/macOS: строки с 192.168.x.x и с tun0
route print   # Windows: колонка «Сетевой адрес»

Если диапазоны пересекаются, лечение одно — сменить подсеть VPN на редкую в строке server, например server 10.66.77.0 255.255.255.0. Диапазоны вида 10.66.77.0/24 или 172.20.30.0/24 в домашних роутерах практически не встречаются. После правки обновите правило MASQUERADE: старое с -s 10.8.0.0/24 перестанет ловить трафик, и вместо причины 6 вы получите причину 2.

Причина 7: MTU и фрагментация

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

ping -c 3 -M do -s 1400 1.1.1.1     # Linux
ping -D -s 1400 1.1.1.1             # macOS
ping -f -l 1400 1.1.1.1             # Windows

Ответ «требуется фрагментация» означает, что размер велик — уменьшайте шагами и найдите наибольший проходящий. Прибавьте к нему 28 байт заголовков IP и ICMP: получится MTU канала, от которого отталкиваются tun-mtu и mssfix в конфиге. Единого правильного числа не существует: мобильные операторы, PPPoE и вложенные туннели дают разный доступный размер, методика подбора расписана в статье про проблему MTU и фрагментацию. Важно: mssfix помогает только TCP, поэтому если сайты выправились, а видеозвонки и игры ведут себя странно, снижать нужно tun-mtu.

Причина 8: у клиента нет прав менять маршруты

Этот случай объясняет странность «на одном устройстве работает, на другом с тем же конфигом — нет». Чтобы завернуть трафик в туннель, клиент меняет таблицу маршрутов системы, а это привилегированная операция.

OpenVPN GUI на Windows без прав администратора подключается, но маршруты не добавляет — в логе будут ошибки на route add; решение — запуск от администратора либо служба OpenVPN Interactive Service. На Linux при запуске не под root маршруты тоже не применятся: нужен sudo или служба openvpn-client@. На macOS клиент запрашивает права системным диалогом, и если его отклонили, разрешение выдаётся в настройках безопасности. Сюда же относится отсутствие script-security 2.

ip route | grep -E "0.0.0.0/1|128.0.0.0/1"   # Linux/macOS
route print 0.0.0.0                          # Windows

Два половинных маршрута 0.0.0.0/1 и 128.0.0.0/1 на адрес туннеля — признак, что redirect-gateway def1 отработал. Их отсутствие означает либо причину 3 (сервер не отдал команду), либо причину 8 (клиент не смог её выполнить); различить помогает лог клиента.

Шпаргалка команд

Со стороны сервера:

sysctl net.ipv4.ip_forward             # включена ли пересылка чужих пакетов
ip route | grep default                # имя внешнего интерфейса
ip a show tun0                         # поднят ли туннель и его адрес
iptables -t nat -L POSTROUTING -n -v   # есть ли NAT, растёт ли счётчик pkts
iptables -L FORWARD -n -v              # не режет ли фаервол транзит
journalctl -u openvpn-server@server -n 50   # последние строки лога
ss -lunp | grep 1194                   # слушает ли OpenVPN свой порт
tcpdump -ni tun0 icmp                  # видит ли сервер пинги от клиента
tcpdump -ni eth0 icmp                  # выпускает ли он их наружу

Пара tcpdump на двух интерфейсах — самая наглядная проверка: пинги видны на tun0, но не появляются на внешнем интерфейсе — вопрос к forwarding и FORWARD; видны на обоих, а ответов нет — к NAT. Подробный разбор захвата — в статье про анализ VPN-трафика через tcpdump.

Со стороны клиента, Linux и macOS:

ip a show tun0                     # адрес внутри туннеля (macOS: ifconfig utun0)
ip route                           # куда реально уходит трафик
resolvectl status                  # какой DNS применён к системе (Linux)
scutil --dns | head -20            # то же самое на macOS
curl -s https://api.ipify.org      # каким IP вас видит интернет
traceroute -n 1.1.1.1              # первый хоп должен быть адресом сервера

Со стороны клиента, Windows (PowerShell):

ipconfig /all                # адрес и DNS адаптера Wintun/TAP-Windows
route print 0.0.0.0          # применился ли маршрут по умолчанию
Get-DnsClientServerAddress   # какие DNS назначены интерфейсам
Resolve-DnsName ya.ru        # проверка резолвинга
tracert -d 1.1.1.1           # идёт ли первый хоп через туннель
ipconfig /flushdns           # сброс кеша имён после смены DNS

Что считать нормальным в выводе трассировки через туннель — тема статьи про traceroute и ping через VPN.

Приёмы, которые экономят время

Отличить клиента от сервера за минуту. Выполните на сервере curl -s https://api.ipify.org: если сервер в интернет ходит, его канал исправен и вопрос в транзите. Затем подключите второго клиента с другого устройства и другой сети. Не работает у обоих — сервер, не работает у одного — клиент.

Читать лог по конкретным строкам. В логе клиента ищите PUSH: Received control message — там перечислено всё, что сервер действительно передал; нет в ней redirect-gateway или dhcp-option DNS — значит, сервер их не отдаёт, и на клиенте искать нечего. Строки add_route показывают попытку изменить маршруты, ошибка рядом — что прав не хватило, а TUN/TAP device tun0 opened подтверждает, что адаптер создан.

Проверить NAT одной командой. Запустите iptables -t nat -L POSTROUTING -n -v дважды с паузой, пока клиент активно грузит что-нибудь. Счётчики pkts и bytes на строке MASQUERADE не изменились — правило не срабатывает: не тот интерфейс, не та подсеть или пакеты до цепочки не доходят.

Изолировать DNS от маршрутизации. Всегда проверяйте ping 1.1.1.1 перед тем, как трогать DNS: половина обращений «VPN не работает» оказывается чистым DNS, и правка NAT только тратит время. Обратное тоже верно — не идёт чистый IP, менять DNS бессмысленно.

Итоговый конфиг и финальная проверка

Минимальный набор строк в server.conf:

server 10.66.77.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 1.1.1.1"
push "dhcp-option DNS 8.8.8.8"

Плюс на уровне системы — net.ipv4.ip_forward=1, правило iptables -t nat -A POSTROUTING -s 10.66.77.0/24 -o <интерфейс> -j MASQUERADE и разрешающие правила FORWARD для tun0. Уровни независимы: форвардинг не заменяет NAT, а NAT не заменяет redirect-gateway. Пропуск любого пункта даёт один и тот же симптом, поэтому по нему одному нельзя угадать, чего не хватает. После перезапуска службы пройдите по клиенту заново:

ping -c 4 1.1.1.1
ping -c 4 google.com
curl -s https://api.ipify.org; echo

IP вашего VPS вместо домашнего в выводе последней команды означает, что трафик действительно идёт через сервер. Если разворачиваете сервер с нуля, разумнее сразу закрыть фаервол правильно — этому посвящена статья про установку и настройку OpenVPN на VPS. Та же по сути проблема есть в WireGuard: WireGuard подключается, но нет интернета.

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