VPN через 4G-модем: особенности настройки

MAATRIX

Если вы пытались поднять VPN-сервер на роутере с 4G-модемом или сим-картой — и ничего не подключилось, хотя конфиг стопроцентно верный, — дело почти наверняка не в настройках. Дело в том, что мобильный интернет в России и большинстве других стран устроен иначе, чем домашний: у вас нет своего белого IP, а входящие подключения оператор просто не пропускает. Ниже — что с этим делать: как проверить, упёрлись ли вы именно в эту стену, и как построить схему, которая через 4G работает стабильно.

Почему 4G-модем не годится на роль VPN-сервера — дело в CGNAT

На домашнем интернете (кабель, оптика) вам обычно достаётся отдельный IP-адрес, пусть даже «серый» внутри локальной сети провайдера — и часто можно попросить оператора выдать белый, статический. С мобильным интернетом так не работает почти никогда: сотовые операторы обслуживают тысячи абонентов через ограниченный пул IPv4-адресов и используют CGNAT — Carrier-Grade NAT, NAT на уровне оператора, а не вашего роутера.

Суть в том, что один внешний IP оператор «размазывает» одновременно на сотни или тысячи абонентских устройств, каждому выделяя диапазон портов. Технически это выглядит так: ваш модем получает адрес вида 10.64.x.x или 100.64.x.x (диапазон CGNAT, RFC 6598) — это уже не настоящий внешний адрес, а внутренний адрес оператора. Реальный публичный IP находится ещё на шаг дальше, на пограничном шлюзе оператора, и от него никто входящий трафик к вам не пробросит — просто потому, что за этим адресом одновременно «прячутся» тысячи разных абонентов, и оператор физически не может решить, кому из них адресован входящий пакет на порт 51820.

Следствие простое: проброс портов (port forwarding) в личном кабинете оператора или в настройках модема не поможет, потому что порт нужно открывать не на вашем устройстве, а на оборудовании оператора — а туда у вас доступа нет. Про классический NAT-проброс на собственном роутере мы разбирали отдельно — проброс портов за NAT; с CGNAT эта техника попросту не работает, потому что NAT там не ваш.

Как проверить, что вы упёрлись именно в CGNAT

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

1. Узнайте, какой адрес модем считает своим внешним. Если это роутер (например, GL.iNet или MikroTik с 4G-модулем), IP интерфейса виден в веб-интерфейсе или командой:

ip addr show wwan0

1. Узнайте, какой адрес видит интернет со стороны, обратившись к любому сервису определения IP:

curl -4 ifconfig.me

Если первый адрес начинается с 10. или 100.64.–100.127. (диапазон RFC 6598), а второй адрес — совсем другое число, вы за CGNAT: между вами и интернетом стоит ещё один слой трансляции адресов, который вы не контролируете. Дополнительно можно посмотреть на TTL входящих пакетов через traceroute — если до внешнего мира больше двух-трёх «невидимых» узлов на стороне оператора, это тоже косвенный признак CGNAT.

Некоторые операторы за отдельную плату предлагают «белый» или полустатический IP на корпоративных SIM-тарифах — если такая опция есть, часть проблем снимается сразу, но входящие подключения всё равно стоит подстраховать схемой ниже, потому что оператор может сменить адрес при перезагрузке модема или смене вышки.

Правильная схема: сервер с белым IP — точка встречи, модем — только клиент

Раз входящие соединения через 4G невозможны в принципе, единственная рабочая архитектура — перевернуть роли. VPN-сервер должен находиться не на 4G-модеме, а на выделенном сервере или VPS с постоянным публичным IP — например, в дата-центре. Модем с сим-картой при этом работает только клиентом, который сам инициирует исходящее соединение к серверу.

Это ключевое отличие от «домашней» схемы, где вы поднимаете сервер дома и пробрасываете к нему порт. Исходящие соединения CGNAT не блокирует — оператор прекрасно пропускает трафик наружу, просто не умеет провести его обратно без установленной сессии. Поэтому:

• VPN-сервер — арендованный VPS/сервер с белым IP (Россия, США или Великобритания — в зависимости от того, куда нужен выход).
• 4G-модем/роутер — выступает VPN-клиентом и сам устанавливает соединение к серверу.
• Все устройства за модемом (офис, домашняя сеть, камеры, IoT) получают доступ через уже установленный туннель — вплоть до удалённого управления самим роутером через VPN-адрес, даже если внешний IP модема меняется каждый час.

Такая схема заодно решает проблему динамического IP: адрес модема на CGNAT может меняться не то что при каждой перезагрузке, а даже посреди сессии, при переключении между вышками. Клиенту это не мешает — он просто переустанавливает соединение к статичному адресу сервера.

Настройка WireGuard-клиента на 4G: почему keepalive обязателен

WireGuard — самый практичный выбор для связки «сервер с белым IP + клиент за CGNAT», он лёгкий и быстро переустанавливает сессию. Но здесь есть тонкость, из-за которой без одной строчки в конфиге туннель через 4G периодически «умирает»: NAT-таблица оператора, через которую проходит ваш трафик, держит запись о соединении ограниченное время — и если пакеты не идут, запись протухает.

WireGuard в режиме клиента не шлёт ничего, если нет активного трафика — а UDP-сессия в NAT-таблице мобильного оператора может закрываться уже через 30–60 секунд простоя (у операторов это не документировано и отличается от сети к сети, поэтому ориентируйтесь на практику, а не на конкретную цифру). Как только запись в NAT-таблице оператора исчезла, входящие пакеты от сервера (те, что сервер пытается отправить клиенту) физически некуда доставить — старое сопоставление порта уже не существует. Клиент выглядит «не отвечающим», хотя формально туннель поднят.

Решение — PersistentKeepalive, параметр, который заставляет клиент периодически слать пустой пакет на сервер, поддерживая запись в NAT живой:

# конфиг на стороне клиента (4G-роутер)
[Interface]
PrivateKey = <приватный_ключ_клиента>
Address = 10.10.10.2/24
DNS = 1.1.1.1

[Peer]
PublicKey = <публичный_ключ_сервера>
Endpoint = <белый_ip_сервера>:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

Значение 25 секунд — стандартная рекомендация из документации WireGuard и разумный компромисс: реже — рискуете попасть в окно, когда NAT уже закрыл сессию, чаще — лишний расход трафика на симке (в мобильных тарифах это может быть заметно, особенно на безлимитках с ограничением по скорости после исчерпания пакета). Если соединение всё равно рвётся, попробуйте снизить интервал до 15–20 секунд — это подскажет, что NAT-таймаут у вашего оператора короче обычного. Про диагностику похожей ситуации на обычном канале, когда handshake проходит, а трафика нет, есть отдельный разбор: WireGuard: handshake есть, а трафика нет — там же описано, как отличить проблему keepalive от проблемы маршрутизации.

OpenVPN через 4G: keepalive, TCP как запасной вариант и переподключение

Если по каким-то причинам используется OpenVPN (например, оператор блокирует характерные UDP-паттерны WireGuard), логика та же: клиент должен сам поддерживать NAT-сессию живой и уметь пережить смену IP при переключении вышек.

В конфиге клиента (client.ovpn) на роутере или модеме важны такие директивы:

client
dev tun
proto udp
remote <белый_ip_сервера> 1194
resolv-retry infinite
nobind
persist-key
persist-tun
keepalive 10 60

• keepalive 10 60 — сервер и клиент обмениваются ping-пакетами каждые 10 секунд, и если за 60 секунд ответа нет, соединение считается разорванным и OpenVPN сам его пересоздаёт. Это одновременно и keepalive для NAT, и механизм обнаружения обрыва.
• resolv-retry infinite — если адрес сервера задан доменным именем, клиент не перестаёт пытаться его резолвить даже после долгого простоя (полезно, если модем на время терял сеть).
• persist-key и persist-tun — не пересоздавать ключи и tun-интерфейс при переподключении, чтобы разрыв был быстрее и незаметнее для приложений внутри туннеля.

Если оператор режет или троттлит UDP-трафик (иногда встречается на «безлимитных» тарифах с ограничением по типу трафика), держите запасной профиль на TCP/443 — он медленнее из-за накладных расходов протокола, но проходит почти через любые ограничения, потому что неотличим от обычного HTTPS:

proto tcp
remote <белый_ip_сервера> 443

Стабильность на 4G: скачки IP, смена вышек и авто-восстановление

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

• Systemd с автоперезапуском. Если клиент поднят как systemd-сервис (стандартно для wg-quick@wg0 или openvpn-client@client), добавьте в unit-файл или override:

[Service]
Restart=always
RestartSec=5

Тогда даже если процесс аварийно завершится из-за потери сети, он поднимется заново без вмешательства.

• Watchdog-скрипт с ping внутрь туннеля. Многие 4G-роутеры (GL.iNet, MikroTik, Keenetic) поддерживают периодическую проверку доступности адреса внутри VPN и автоматический рестарт интерфейса при её провале — это надёжнее, чем полагаться только на встроенный keepalive протокола, потому что ловит и случаи, когда туннель «жив» формально, но трафик не проходит. Похожий сценарий постоянного VPN на выезде разобран в статье про travel-роутер как постоянный VPN в поездках — там та же логика нестабильного канала, только вместо 4G-модема бывает публичный Wi-Fi.
• Внешний мониторинг доступности. Раз VPN-сервер обычно ещё и обслуживает другие задачи (удалённый доступ в офис, IoT), стоит следить за его доступностью со стороны — не только «жив ли процесс», но и «отвечает ли реально». Как настроить такой контроль, описано в статье про мониторинг доступности VPN-сервера через Uptime Kuma; применительно к 4G-схеме имеет смысл мониторить не столько сам сервер (он обычно стабилен), сколько факт, что конкретный клиент из-за модема регулярно выходит на связь.

Отдельно взвесьте расход трафика: keepalive-пакеты и переустановка сессий при потере сигнала — это постоянный фоновый трафик, обычно единицы мегабайт в сутки, но на тарифах с жёстким лимитом это стоит учитывать при выборе плана.

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