Что можно сделать для миграции сетевых приложений, если конфигурацию клиента изменить нельзя?
У нас есть ряд ситуаций, когда клиентское приложение необходимо перенести с одного хоста на другой в активной производственной сети. На серверах продолжают работать другие приложения.
Проблема в том, что удаленное приложение обычно работает на какой-либо встроенной системе, и из соображений избежания риска не разрешается вносить изменения в конфигурацию этих удаленных приложений.
Я вижу, что маршрутизатор с (вероятно, изрядной) конфигурацией NAT можно сделать так, чтобы это изменение прозрачно влияло на передачу трафика на другой хост в сети, не касаясь устройства. Мы могли бы убедить нас в некоторых изменениях на сетевом уровне, но даже они не приветствуются.
Во-первых, правильный ли это подход, если невозможно избежать зависания, а во-вторых, есть ли у кого-нибудь идеи (а еще лучше готовый набор правил iptables) для реализации чего-то подобного?
редактировать
Я намеренно не уточнял, но это может прояснить ситуацию. Клиентские приложения обычно представляют собой встроенные устройства с проприетарными протоколами потока TCP. Ограничение в частности заключается в том, что мы не можем изменять конфигурацию устройства и настоятельно не хотели бы изменять конфигурацию сети или сервера. Это вызвано как риском, связанным с неопределенностью, так и доступностью инструментов для управления устройствами. Существует множество различных типов устройств с определенным профилем, и это не единственное общее решение.
Это действительно требует, чтобы какое-то оборудование было установлено на краю сети для реализации перенаправления.
Я понимаю, что это нельзя считать хорошей практикой, но это то, что мы унаследовали и не можем контролировать. По мере продвижения вперед мы изменим протоколы на те, в которых устройства либо можно соответствующим образом настраивать, либо использовать устройства, которые действуют как серверы, чтобы избежать этой проблемы.
Схема, показывающая типичную требуемую конфигурацию, показана ниже.
Учитывая ваши ограничения, я бы предложил брандмауэр, который перенаправляет TCP-трафик на основе IP-адреса источника. Это легко сделать с помощью ipf или iptables или любого специального брандмауэра, о котором я могу вспомнить.
Вот несколько основных советов по iptables, которые помогут вам начать:
Сначала скажите серверу выполнить пересылку (если это еще не сделано)
sysctl net.ipv4.ip_forward=1
Затем настройте правило для конкретного исходного IP-адреса устройства, которое вы хотите перенаправить:
iptables -t nat -A PREROUTING -s 1.1.1.1 -p tcp --dport 1111 -j DNAT --to-destination 2.2.2.2:1111
(Здесь 1.1.1.1 - источник, 2.2.2.2 - новая цель, а порт на цели - 1111)
Вам также необходимо указать iptables маскировать IP-адрес.
iptables -t nat -A POSTROUTING -j MASQUERADE
Впоследствии у нас был маршрутизатор Mikrotik, настроенный как мост с поддержкой трансляции адресов L3.
Маршрутизатор размещается между устройством и сетью и динамически транслирует каждый кадр Ethernet, содержащий IP-адрес хоста, в адрес хоста.
У меня были предложения, в которых использовалось решение исключительно на основе маршрутизатора путем введения дополнительного сегмента сети между двумя портами в маршрутизаторе, но я считаю, что решение L2 с большей вероятностью будет стабильным.
Ожидаемая скорость трафика настолько низка, что начальный уровень RB750 обеспечивает более чем достаточную пропускную способность.
Это зависит от вашей ситуации и количества шагов, которые требуется клиенту для доступа к серверному приложению.
Обычно вы копируете один клиент для тестирования, реальный сервер приложений и создаете новый сервер приложений, перепроектированный для вашего скопированного клиента.
Количество шагов используется для определения, на каком шаге вы отправляете запрос на новый сервер приложений. немного вроде этого (это должно быть сделано полностью виртуально и отдельно от реального)
Client -> request -> sep1 -> stop2 -> server this -> server that -> done.
Итак, шаг «server that» - это первый шаг, который вы должны изучить и перенаправить на ваш новый сервер приложений. если это работает в фальшивой среде, вы переходите к шагу «server this», «stop2» и так далее, пока вы не выполните полностью переработанный новый сервер приложений. это скорее модель разбивки, чем реальное правило iptables, но я надеюсь, что вы уловили идею.
Вот почему был изобретен DNS. Не указывайте жестко IP-адреса на встроенных устройствах, так как они со временем изменятся (как вы сейчас видите). Затем при перемещении служб на другой хост просто обновляется DNS-имя, используемое для этой службы.