Я ищу решение, которое позволило бы мне получить удаленный доступ к нескольким устройствам с центрального сервера.
На устройствах предустановлено специальное программное обеспечение, но состояние их сети будет неизвестно и, вероятно, в средах WiFi с ограничением 3G или NAT.
Первое, о чем я подумал, - это использовать обратные SSH-соединения (либо с ssh -R через службу systemd, либо с autoSSH), хотя это подразумевает наличие одного перенаправленного порта для каждого устройства. На самом деле это не проблема, и я сомневаюсь, что у меня одновременно будет работать более ~ 50K устройств.
Однако я ищу более простую в управлении инфраструктуру и более масштабируемую, на всякий случай. Я пытался ответить на другие вопросы, но не могу найти ответа на эту проблему. Я вижу, что некоторые рекомендуют использовать VPN-туннели, подключая каждое устройство к центральному. Если бы кто-то просто мог объяснить, как это работает, было бы здорово, я действительно не понимаю, как это будет работать, где мне настроить каждый идентификатор / имя устройства и как мне запустить удаленное соединение, когда оно все работает.
Также приветствуется любой другой подход или решение.
Примечание 1: удаленного доступа по одному, я думаю, достаточно, но если все, где это возможно (чтобы отправлять команды группе устройств), также будет полезно (но не прекращайте отвечать, если решение по одному в вашей голове. ).
Примечание 2: системы основаны на debian. (Raspbian. Это также может быть Ubuntu, если необходимо)
Используя модный термин «Интернет вещей», мы регулярно получаем такие вопросы. Я добавлю длинный ответ с некоторыми соображениями и предложу другим отредактировать и улучшить.
Откажитесь от идеи интерактивного доступа к любому конкретному устройству. Вам понадобится агент на устройстве, который принимает инструкции / команды с сервера управления и отправляет обратно свое состояние и любые результаты / собранные данные. Оператору на месте было бы полезно получить подтверждение, что устройство действительно обменивается данными с вашим сервером управления или ошибочно.
Ваши устройства должны позвонить домой.
Вы хотите, чтобы ваши устройства подключались к вашему серверу (-ам) управления, а не наоборот. Поскольку IPv4 все еще используется многими потребителями и предприятиями, также существует довольно много NAT, при котором установление соединения от устройства к вашему серверу будет работать гораздо более плавно, чем наоборот (для этого потребуется настроить переадресацию портов и т. Д.) .
Поведение по умолчанию большинства межсетевых экранов для потребителей и малого бизнеса - разрешить весь исходящий трафик, и поскольку они часто не управляются, это означает, что звонок домой часто будет работать без дополнительной настройки.
Даже многие управляемые сети предпочитают разрешать исходящие соединения, а не открывать входящие.
Протокол должен быть HTTP или скорее HTTPS. Это работает через обычный TCP / IP, и даже если прямой доступ в Интернет не разрешен, ваши устройства все равно можно легко настроить для использования веб-прокси.
Ваш сервер управления должен прослушивать веб-порты по умолчанию т.е. 80 (HTTP) и / или 443 (HTTPS). О том, чтобы следовать за ордой, можно многое сказать ...
Ваши устройства должны иметь возможность настраивать себя с помощью DHCP но вам также необходимо будет предложить оператору на месте способ настройки статической IP-конфигурации и / или прокси-сервера.
Ваши устройства должны будут поддерживать как IPv6, так и IPv4.
Автоматическое зачисление - с большим количеством устройств вы, вероятно, не захотите (вручную) регистрировать каждое устройство на сервере управления перед его развертыванием, вместо этого устройство, вероятно, должно регистрироваться при включении и подключении.
Агент не должен работать по фиксированному расписанию, вы не хотите, чтобы тысячи агентов звонили домой в один и тот же момент.
Возможно, вы захотите взглянуть на существующие инструменты управления конфигурацией которые уже предлагают множество таких функций.
Если вы решили развернуть свой собственный, рассмотрите возможность использования таких фреймворков, как Пакет SDK для шлюза Интернета вещей Azure, Google Compute IoT или AWS IoT