Проброс портов

Проброс портов публикует HTTP-службу, работающую на серверной машине — сервер разработки, панель управления устройством, что угодно, слушающее обычный адрес http://localhost:port, — на отдельном TLS-порту, так что любое устройство, имеющее доступ к серверу, открывает её в браузере как https://<адрес-сервера>:<порт>/.

Как это работает

• Проброс сопоставляет целевой порт — HTTP-службу на этой машине — с проброшенным портом, выделяемым из настроенного диапазона портов (по умолчанию 62000–62999);
• Проброшенный порт говорит по TLS: весь трафик шифруется самоподписанным сертификатом сервера — ничего не передаётся открытым текстом, даже по недоверенной сети;
• Любое устройство, имеющее доступ к серверу — в LAN или из интернета, когда диапазон портов проброшен на маршрутизаторе, — открывает https://<адрес-сервера>:<проброшенныйПорт>/ и попадает на локальную службу.

Пробросы создаются по требованию: общий доступ к файлам Host with HTTP server на удалённом (подключённом через релей) сервере автоматически запрашивает проброс и выдаёт готовый к открытию URL. Никакой ручной настройки не требуется.

Управление пробросами

1. Откройте раздел Port Forwarding веб-интерфейса сервера.
2. Port Range Configuration ограничивает пул, из которого выделяются проброшенные порты; изменения сохраняются автоматически. Сузьте его, если ваш брандмауэр или маршрутизатор пробрасывает лишь несколько портов.
3. Активный список показывает каждый проброс как :проброшенныйПорт → :целевойПорт с количеством активных подключений.
4. Кнопка остановки проброса немедленно снимает слушатель и разрывает его активные подключения; следующий общий доступ выделит свежий порт. Refresh перечитывает список.

Предупреждение о сертификате

Пробросы шифруются собственным самоподписанным сертификатом сервера — тем же, что защищает веб-интерфейс и клиентские подключения. Браузеры не могут проверить его по центру сертификации, поэтому первый визит по проброшенному URL показывает предупреждение о конфиденциальности (Подключение не защищено). Это ожидаемо и безопасно пропустить: само шифрование не скомпрометировано, лишь происхождение сертификата не может быть проверено автоматически. Чтобы навсегда убрать предупреждение, импортируйте сертификат сервера в хранилище доверенных сертификатов вашего устройства.

Chrome на macOS показывает ERR_ADDRESS_UNREACHABLE

На macOS 15 (Sequoia) и новее сторонним приложениям нужно явное разрешение на доступ к устройствам в локальной сети — к любому адресу вида 192.168.x.x, 10.x.x.x и подобным. Safari как системное приложение освобождён от этого, поэтому проброшенный URL может нормально открываться в Safari, тогда как Chrome сообщает ERR_ADDRESS_UNREACHABLE ещё до начала TLS. Это не проблема сертификата и не проблема самого проброса.

Чтобы дать Chrome доступ:

1. Откройте Системные настройки → Конфиденциальность и безопасность → Локальная сеть.
2. Найдите Google Chrome в списке и включите его.
3. Полностью завершите Chrome (Cmd+Q, а не просто закрытие окон) и запустите заново.

Если переключатель уже включён, выключите его и включите снова — он может зависнуть после обновления Chrome или macOS. Если ошибка сохраняется, проверьте, нет ли в Chrome VPN- или прокси-расширения, которое не маршрутизирует частные диапазоны адресов.

Контроль доступа

Что защищает проброшенный порт, зависит от того, что за ним:

• Встроенные публикации защищены токеном. Ссылки, которые создаёт клиент, — публикация Host with HTTP server (?share_token=…) и страница Settings (?ticket=…) — содержат токен доступа. Соединение без действующего токена и без действующей сессии обрывается до отдачи какого-либо содержимого. При первом посещении браузер обменивает токен на защищённую сессионную cookie, действующую только для этого сервиса, а сам токен исчезает из URL — он не остаётся ни в адресной строке, ни в истории.

• Токены одноразовые и короткоживущие. Билет Settings срабатывает ровно один раз и истекает через минуту; когда публикация останавливается или перезапускается, прежние ссылки и сессии перестают работать. Считайте полную ссылку паролем — у кого она есть, тот получает доступ к сервису — и передавайте её только тем, кому доверяете.

• Свои сервисы защищает их собственная аутентификация. Проброс к любому другому локальному сервису шифрует трафик самоподписанным сертификатом сервера, но аутентификации не добавляет: всё, что отдаёт сервис, — и страницы, и API, — доступно каждому, кто достучится до порта. Добавьте аутентификацию на чувствительные службы перед их публикацией.