Хотспот за NAT, Wi-Fi и в дороге: нужен ли проброс портов и LTE

«Поставил хотспот, а в роутере надо что-то пробрасывать? У меня же серый IP от провайдера…» — это, наверное, самый частый вопрос новичка. Хорошая новость: в подавляющем большинстве случаев пробрасывать ничего не надо. MMDVM-хотспот сам звонит мастер-серверу — устанавливает исходящее соединение, а не ждёт входящего. Поэтому он спокойно работает за домашним NAT, на мобильном интернете, в гостиничном Wi-Fi и из машины через LTE-модем. В этой статье разберём, почему так устроено, когда всё-таки бывают проблемы (CGNAT, блокировки, брандмауэр), как запитать хотспот в дороге и что делать, если он «не подключается».

Почему проброс портов обычно не нужен

Чтобы понять логику, надо знать, кто кому звонит. Хотспот с прошивкой Pi-Star/MMDVMHost подключается к сети (BrandMeister, наш DMRhub-мастер, XLX-рефлектор) по протоколу Homebrew/MMDVM поверх UDP. Инициатором всегда выступает хотспот: он отправляет наружу пакет логина (RPTL) на адрес и порт мастера, проходит авторизацию, а дальше «канал» поддерживается периодическими keep-alive — обмен ping/pong в обе стороны.

Когда ваш хотспот отправляет UDP-пакет в интернет, роутер запоминает это в таблице трансляции адресов (NAT/conntrack) и автоматически возвращает обратно ответы, пришедшие с того же адреса. Это та же механика, по которой у вас в браузере открываются сайты без всякого проброса. Поэтому:

• Серый/«домашний» IP за NAT — нормально. Исходящему соединению не нужен белый адрес.
• Гостевой Wi-Fi у друзей, на работе, в отеле — обычно работает, если наружу пускают UDP.
• Мобильный интернет (LTE/4G/5G) — работает, хотя у сотовых операторов почти всегда CGNAT (про него ниже).

Какие порты при этом задействованы

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

CGNAT и «симметричный» NAT: когда теория встречает оператора

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

Но нашему хотспоту входящий проброс и не нужен! Для исходящего UDP CGNAT почти никогда не помеха: пакет уходит наружу, оператор держит трансляцию, ответы возвращаются. Поэтому хотспот за CGNAT, как правило, прекрасно подключается к мастеру. Тонкие места всё же есть:

• Короткие тайм-ауты трансляции. Некоторые операторы быстро «забывают» UDP-сессию без трафика. Из-за этого канал может изредка отваливаться и переподключаться. Лечится тем, что Pi-Star и так шлёт keep-alive — обычно сессия живёт.
• Симметричный NAT. Для простого «клиент → сервер» он не мешает: мастер отвечает с того же адреса и порта, куда пришёл логин. Проблемы симметричного NAT касаются P2P/STUN-сценариев, а не нашей клиент-серверной схемы.
• Двойной NAT дома. Если роутер стоит за роутером (например, ваш Wi-Fi роутер за роутером провайдера) — для исходящего UDP это тоже не проблема. А вот если бы вам понадобился входящий проброс, двойной NAT его бы убил.

Хотспот на мобильном интернете: LTE-модем и смартфон

Раз входящий проброс не нужен, хотспот легко выходит в эфир там, где есть только сотовая связь — на даче, в поездке, в машине. Есть два рабочих варианта.

Смартфон в режиме точки доступа (самый простой)

1. Включите на телефоне «Точка доступа Wi-Fi» (режим модема).
2. Пропишите имя сети (SSID) и пароль этой точки в Wi-Fi-настройках хотспота.
3. Поднимите хотспот — он подключится к телефону, а через него выйдет к мастеру.

USB-LTE-модем или 4G-HAT (стационарнее)

Для постоянного «мобильного» узла удобнее воткнуть USB-донгл или 4G-плату расширения прямо к одноплатнику. Минус — настроить интерфейс модема под Linux чуть сложнее, чем просто ввести пароль Wi-Fi. Плюс — телефон остаётся свободен, а узел автономен.

Питание в дороге: сколько ест хотспот

Главный плюс хотспота для путешествий — крошечное потребление. Одноплатник Raspberry Pi Zero (W/2 W) с MMDVM-платой в работе тянет ориентировочно ~100–250 мА при 5 В (порядка 0,5–1 Вт в среднем; пики при передаче и старте выше). Это значит, что обычный повербанк держит узел очень долго.

Цифры ориентировочные: реальная отдача повербанка ниже паспортной (КПД преобразования, саморазряд, просадка к концу), плюс Wi-Fi и LTE-модем добавляют расход. Но порядок понятен — это совсем не прожорливый прибор.

«Хотспот не подключается»: диагностика по шагам

Если на дашборде Pi-Star мастер «красный» / Disconnected, идите по порядку — от простого к сложному. В 90% случаев виновата одна из четырёх причин: интернет, время/DNS, адрес мастера, питание.

1. Есть ли вообще интернет. Зайдите на дашборд хотспота и проверьте, видит ли он сеть. Самый быстрый тест — подключить хотспот к телефону в режиме модема: заработало → проблема в исходной сети (фильтрация/блокировка), а не в хотспоте.
2. Время и DNS. Это классическая ловушка. У Raspberry Pi нет встроенных часов с батарейкой (RTC), поэтому после долгого простоя без сети время «уезжает». А при неверном времени ломается проверка подписей DNSSEC — резолвер начинает считать ответы DNS «протухшими» и не отдаёт IP. Получается замкнутый круг: «нет времени, потому что нет DNS, и нет DNS, потому что неверное время». Разрывается перезагрузкой с интернетом, ручной синхронизацией NTP или разовой установкой даты вручную.
3. Адрес и код мастера. Проверьте в настройках: правильно ли выбран сервер (Master), указан ли верный пароль/security code, ваш позывной и DMR ID. Опечатка в коде или старый адрес мастера = «логин отвергнут».
4. Питание. Иконка молнии, спонтанные перезагрузки, пропажа Wi-Fi — почти всегда недокорм по питанию (см. блок выше). Поменяйте кабель и источник на заведомо хорошие.

# Ручная синхронизация времени на Pi-Star (по SSH)
sudo systemctl stop ntp.service
sudo ntpdate pool.ntp.org      # подтянуть точное время
sudo systemctl start ntp.service

# Если ntpdate в системе нет (на новых сборках он удалён) —
# выставьте дату вручную, дальше ntp сам подтянет точное время:
sudo date -s "10 JUN 2026 12:00:00"

# Проверить связь и DNS
ping -c3 dmrhub.ru             # резолвится ли и пингуется ли мастер
date                          # верное ли время

Когда проброс портов всё-таки нужен

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

• Доступ к дашборду Pi-Star снаружи. Если хотите открывать веб-морду хотспота из интернета (не из домашней сети) — тогда нужен проброс/туннель. Но выставлять админку наружу небезопасно; лучше VPN.
• Свой мастер-сервер. Если вы поднимаете сам сервер сети (а не клиента-хотспот) — вот ему нужен белый IP и открытый входящий порт, потому что к нему стучатся хотспоты. Это другая роль.