P2P-доступ к камере без белого IP: как это работает и почему это безопасно

«Чтобы смотреть камеру из интернета, нужен белый IP и проброс порта» — это устаревшая формула. Современные облачные сервисы (РуКлауд, Ivideon, Line и другие) обходятся без неё, и это не только удобнее, но и безопаснее. Разбираемся, как они это делают.

Проблема: камера за NAT

Типичная домашняя или офисная сеть: роутер с одним внешним IP, за ним — десятки устройств с серыми адресами 192.168.x.x или 10.x.x.x. Это NAT (Network Address Translation). Извне вы не можете обратиться к конкретному устройству — вы упираетесь в роутер, который не знает, кому именно пакет предназначен.

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

• Нужен белый (публичный) IP. У провайдеров он либо вообще не выдаётся, либо платный (300–500 ₽/мес).
• Нужно уметь настраивать роутер. Половина пользователей боится это делать самостоятельно.
• Камера становится видимой в интернете. Её найдут Shodan, Censys и другие сканеры в течение часов. Дальше — брутфорс паролей, попытки эксплойтов прошивки.
• Плюс адрес с ростелекомовского CGNAT внезапно меняется, и всё отваливается.

Как устроен P2P

Идея: пусть камера сама устанавливает соединение с облаком (исходящее — NAT пропускает), и поддерживает его постоянно. Когда клиент (мобильное приложение или браузер) хочет посмотреть видео, он обращается к облаку, которое уже знает, как достучаться до камеры.

Но есть нюанс: если транслировать видео через облако, нужны серверы с большим объёмом трафика. 50 000 камер × 2 Мбит/с = 100 Гбит/с пиковой пропускной способности, и это очень дорого. Поэтому используют peer-to-peer: клиент и камера устанавливают прямое соединение, видеопоток идёт напрямую, минуя облако.

Как возможно прямое соединение, если обе стороны за NAT? Тут включается магия ICE (Interactive Connectivity Establishment).

STUN, TURN и ICE

STUN — разузнать свой внешний адрес

Камера отправляет UDP-пакет на STUN-сервер (например, stun.rucloud.invill.space:3478). Сервер видит «о, ко мне пришёл пакет с внешнего IP 89.22.14.5:49152» и отвечает камере этой информацией. Камера теперь знает свой внешний endpoint.

Аналогично клиент узнаёт свой внешний endpoint.

UDP Hole Punching — пробить дырку через NAT

Хитрый момент. Оба участника через сигнальный канал (TCP к облаку) обмениваются парами endpoint-ов. Дальше они одновременно отправляют друг другу UDP-пакеты на эти адреса.

С точки зрения NAT роутера камеры: «исходящий пакет на адрес 88.21.50.11:49832 — запомню эту связку и разрешу входящие от неё». С точки зрения NAT клиента — то же самое. В итоге через пару раундов рукопожатия NAT-ы с обеих сторон «открывают дырку», и прямое соединение установлено.

Это работает для Cone-NAT (большинство домашних роутеров, мобильные сети ~70% операторов). Не работает для Symmetric-NAT — некоторые корпоративные сети, часть операторов CGNAT.

TURN — резервный канал через сервер

Если Hole Punching не сработал, ICE падает на TURN (Traversal Using Relays around NAT). Это ретранслятор: клиент и камера обе подключаются к одному и тому же серверу, а он проксирует трафик. Медленнее, дороже (платится трафиком сервиса), но работает всегда.

По нашей статистике в РуКлауд, 80–85% сессий устанавливаются прямым P2P, 15–20% уходят в TURN. На рабочих сетях корпоративных клиентов TURN может доходить до 40%.

Сигнальный канал

Для ICE нужен сервис, через который стороны обменяются кандидатами. В классике WebRTC — отдельный сигнальный сервер. У нас он называется RuCloud Broker и работает по WebSocket + TLS 1.3. Каждая камера держит постоянное исходящее подключение к нему.

В этом же канале передаются:

• Команды управления (старт/стоп потока, снимок, PTZ, двусторонняя связь).
• События от камеры: движение, тревога, потеря связи с облаком.
• Heartbeat каждые 30 секунд — чтобы вовремя заметить, что камера упала.

Сигнальный канал маленький по трафику (десятки килобайт в минуту), но требовательный к latency — все команды на PTZ должны долетать быстро.

End-to-end шифрование

Видеопоток идёт по UDP с SRTP (Secure RTP). Ключи устанавливаются через DTLS (аналог TLS, но для UDP). Это означает:

• Видеопоток зашифрован между камерой и клиентом.
• TURN-сервер (если используется) видит только шифрованные пакеты, не может расшифровать.
• Даже если кто-то перехватит трафик посередине — увидит только байтовую кашу.

Используется AES-128-GCM, обмен ключами ECDHE с P-256. Сертификаты с обеих сторон самоподписанные, доверие устанавливается через сигнальный канал — обе стороны сравнивают отпечаток сертификата, переданный облаком, с тем, что получили при DTLS handshake.

Сравнение с традиционным подходом

А что с безопасностью?

Главное возражение от «староверов»: «вы отправляете моё видео через облако, это небезопасно». Разберём:

• Видео зашифровано end-to-end. Никто на промежуточных серверах его не видит.
• Камера не видна снаружи. Никто не может к ней постучаться с попыткой брутфорса или эксплойта прошивки.
• Авторизация. Камера привязана к вашему аккаунту. Для подключения клиент проходит стандартную OAuth-авторизацию.
• Двухфакторка. Включаете 2FA — злоумышленник с паролем не сможет зайти в кабинет.
• Журнал доступа. Видите кто, когда, с какого устройства смотрел вашу камеру.

Парадоксально, но P2P через облако безопаснее, чем проброс портов: в первом случае поверхность атаки — только ваш облачный аккаунт (охраняемый 2FA), во втором — сама камера с её дефолтными паролями и годами не обновляемой прошивкой.

Что выбрать вам

Для 99% задач (дом, офис, магазин, небольшое производство) — облачный P2P. Проще, безопаснее, не зависит от провайдера.

Для объектов с особыми требованиями (банки, оборонка, госсектор) — гибрид: локальный NVR (NVR-16) + клиент в корпоративной сети по VPN. Наружу в интернет ничего не смотрит.

Для частных случаев (камера в закрытом сегменте без интернета вообще) — классическая локальная система с RTSP и проброс только в локальную сеть. Но это скорее экзотика — большинство задач закрывается первыми двумя вариантами.

Подробнее про угрозы безопасности IP-камер и как их закрыть — читайте в статье «Топ-10 ошибок безопасности».