У меня есть серверная система, используемая для устройств IOT, которые используют протокол UDP для связи. И есть определенные API на основе TCP (HTTP2) для мобильных приложений из того же бэкэнда.
Я пытаюсь создать функцию непрерывного обновления, чтобы обеспечить исправление нулевого времени простоя серверных служб.
Моя установка такая.
Вместо того, чтобы напрямую открывать сокеты приложениям, я пытаюсь сделать прозрачный прокси для своих процессов. Я выставил 2 сокета (1 udp и 1 tcp) в общедоступный Интернет с помощью брандмауэра.
Мой рабочий сервер открывает другой набор портов для udp и tcp (которые можно изменить с помощью переменных среды без изменения базового двоичного файла).
Шаг 1:
Я пытаюсь создать прозрачный прокси-сервер на той же машине с udp-порта 16002 на 17002. Для udp мой сервер также инициирует некоторую связь с устройствами в дикой природе. Сервер должен видеть исходный IP/порт, а также обмениваться данными с этими устройствами, которые могут находиться под некоторыми NAT. (как правило, WiFi-маршрутизатор), соблюдая политику одинакового происхождения NAT.
И то же самое для tcp. С порта 16012 на порт 17012.
Это типичное развертывание путем экстернализации реальных портов.
Я не могу сделать эту работу.
Шаг 2:
Всякий раз, когда нужно исправить новый код, я хочу запустить новый код на двух разных наборах портов, как показано на рисунке ниже (P2 — Процесс 2).
Когда процесс 2 запущен и запущен, я изменю сопоставление IP-адреса с новым процессом (P2). Предоставив P1 определенное время для завершения любых ожидающих операций ввода-вывода, мы остановим процесс P1.
Для следующего патча мы поднимем P1 'и процесс будет обратным.
Есть ли недостатки в этой конструкции? Можно ли этого добиться технически, используя iptables и tproxy или любые другие инструменты Linux?
Я рассматривал возможность создания маршрутизатора L7 и ретрансляции пакетов туда и обратно с помощью определения объектов высокого уровня. Но мне любопытно, можно ли это сделать с помощью низкоуровневой маршрутизации L3/L4, поскольку она может быть более эффективной и проверенной в бою. Конечно, эти инструменты nft, iptables имеют проблемы с удобством использования и не очень интуитивно понятны, особенно nft, для разработчика.