Мне нужен совет от вас, ребята: я имею дело с настраиваемым балансировщиком нагрузки / программным обеспечением, для которого мы будем использовать 2 основных сервера и около 8 подчиненных серверов. Вкратце: пользователь отправляет запрос на главный сервер, основной сервер будет получать и обрабатывать запросы, отправляет запрос на подчиненный сервер, а подчиненный сервер должен отправлять данные НАПРЯМУЮ "пользователю".
Пользователь -> Главный сервер
Главный сервер -> Ведомый сервер
Подчиненный сервер -> Пользователь
Теперь у меня есть следующая идея: -IPinIP, но это невозможно в Layer7 (пока я знаю, что для этого есть несколько дорогих маршрутизаторов) -IP Spoof, используя C / C ++, мы сделаем так, как будто ответ пришел с основного сервера.
Но я подумал, возможно, ответ «подчиненный сервер -> Пользователь» мог просто прийти с другого IP-адреса, не вызывая проблем в брандмауэре со стороны пользователя или его антивируса. Я не очень хорошо разбираюсь в «домашних» межсетевых экранах / маршрутизаторах и / или антивирусном ПО. Полагаю, пользовательская машина не справится с этим?
Я считаю, что это зависит от того, как можно настроить настраиваемый балансировщик нагрузки (я предполагаю, что главный сервер, как указано в вашей схеме) и приложение подчиненных серверов. Есть два принципа, которые часто используются в балансировщиках нагрузки для создания реальной структуры маршрутизации запросов / ответов:
1) Если вы можете указать главному серверу не использовать свой собственный IP-адрес в качестве исходного IP-адреса, а вместо этого IP-адрес клиента (например, был в пакете, когда он пришел на главный сервер в первую очередь, в соответствии с вашей схемой) при передаче пакета ведомым устройствам. Подчиненный сервер, естественно, отправит свой ответ напрямую клиенту, а не через основной. Это довольно распространенная функция, которую можно увидеть в балансировщиках нагрузки, мы, сетевые специалисты, часто называем перезапись исходного кода «исходной натурой», а не подделкой IP-адреса, чтобы отличить доброкачественное намерение, и с помощью которой вы должны иметь возможность сделать некоторые интересные поисковые запросы по этой теме.
2) Другой вариант дизайна - встраивание метаинформации, аналогичной заголовку X-Forwarded-For, в http или в поле remote_addr / remote_host (не могу вспомнить, какое) в ajp, которые используются для переноса исходного IP-адреса клиента как части данных. поле, даже если оно было заменено адресом промежуточного хоста в пакете ip. Если с помощью используемого вами протокола можно достичь чего-то подобного, вашим главным серверам потребуется ввести эту метаинформацию в поле выбора. Приложение на ваших подчиненных серверах должно быть проинструктировано отправлять ответ на адрес в этом поле, а не на исходный адрес в пакете ip. Одним из преимуществ этого дизайна является то, что он обеспечивает отличное ведение журнала, поскольку вы получаете доступ ко всем адресам узлов, которые были задействованы в конкретном потоке.
Это из принципа, на практике вы можете немного споткнуться, если клиент ожидает, что ответ от ведомого устройства будет частью того же сеанса, что и запрос (и так далее, и тому подобное). Все зависит от ожиданий протокола, который вы пытаетесь передать, и от того, какая инфраструктура у вас есть вокруг вашего сервиса, чтобы разгадывать все вместе для вас :-)