Блог

снова я борюсь с недостатком знаний протокола.

Базовая ситуация:

Устройство A хочет взаимодействовать с устройством Z через HTTPS.

Устройство A подключено не к Интернету, а только к внутренней сети, разрешающей только MQTT. Давайте назовем это «внутренней шиной» B. Также к B подключен шлюз MQTT -> HTTPS G, который имеет доступ в Интернет.

Вопрос:

Можно ли было бы обернуть весь HTTPS-трафик между A и Z в полезные нагрузки MQTT и использовать эти MQTT-Пакеты также для установления связи и передачи данных — таким образом, чтобы устройства A и Z не были «нарушены» при их HTTPS-связи?

Это не относится к какой-либо расшифровке пакетов: все должно быть обернуто как есть в MQTT и перенаправлено через G — так что это было бы что-то вроде уровня 8 OSI.

Оценка:

Мое внутреннее чувство подсказывает, что это должно как-то сработать, но я думаю, что для достижения этого мне пришлось бы написать свой собственный «сетевой драйвер» или «сетевой хук» на устройстве A и на шлюзе G

Что вы думаете о возможности?

Спасибо и с наилучшими пожеланиями

Хотя это возможно (возможно почти все, если вы достаточно постараетесь, люди написали целые VPN, которые работают через DNS-запросы) Я бы поставил под сомнение возврат инвестиций.

Вам понадобятся 2 темы, по одной для каждого направления связи и устройство tun / tap на шлюзе для записи / чтения пакетов. Добавьте уровень NAT, и он будет работать на уровне IP, а не на уровне HTTP-прокси.

Если вас беспокоит безопасность и по какой-либо причине вы не можете (или не нуждаетесь в этом) использовать MQTT поверх TLS в локальной сети, вы можете использовать обратный прокси-сервер для завершения TLS на границе локальной сети. Это довольно легко сделать с помощью Nginx (подробно описано в статье ниже)

https://docs.nginx.com/nginx/admin-guide/security-controls/terminating-ssl-tcp/

Если по какой-то причине вам абсолютно необходимо использовать HTTPS, шлюз протокола должен сделать свое дело, но я бы не стал этого делать, если бы мне не было абсолютно необходимо.