Вы упомянули что некую "защиту от DDoS" вам предоставляет хостер (можете кстати уточнить модель аппаратного решения?). Если предположить, что ваши сервисы используют UDP (что, думаю, корректно для случая с CS-подобными игровыми серверами без дополнительных оберток трафика), то мысли такие.
Я полагаю, что максимум, что хостер может сделать - это ограничить трафик до сервера при DDoS-атаках (policing, причем хорошо, если политики учитывают порты назначения, а не только IP-адреса) или полностью заблокировать трафик до одного сервера, спасая инфраструктуру от чрезмерного трафика (bgp blackhole к аплинкам, эффективно атакуемый сервер все равно будет недоступен).
При использовании UDP возникает проблема аутентификации трафика. При использовании TCP есть возможность отделить тех, кто действительно устанавливает соединение, от тех, кто шлет SYN-сегменты с подставными адресами - вторые не смогут ответить ACK-сегментом с правильным значением acknowledgement на наш SYN-ACK-сегмент (ну или есть варианты с специально сформированным кривым SYN-ACK ответом, легитимный хост ответит RST c правильным acknowledgment и перепошлет SYN через примерно 3 секунды). В случае с UDP мы такой роскоши лишены. Мы не можем средствами самого UDP определить, кто подделывает адреса, а кто является легитимным хостом. Полагаю, неплохим решением было бы вести на сервере список IP-адресов клиентов и каким-либо образом передавать его хостеру, чтобы он в случае атаки блокировал весь трафик, не удовлетворяющий списку. Но хостер не внедрит новомодныя SDN-технологии (программно-определяемые сети) и не даст вам доступ к соответствующему API, это будет довольно затруднительно организовать.
Далее, что касается проксирования трафика. Самый наивный вариант -
udp-прокси, т.е. сокет на сервере 1 принимает данные и копирует их в сокет, отправляющий данные на сервер 2. На сервер 2 пакеты, вмещающие соотвествующие датаграммы, придут с полем адреса источника, равном адресу сервера 1. Со стороны сервера 2 будет казаться, что все игроки имеют один и тот же адрес (если не предпринять никаких мер на уровне приложения, например добавлять в датаграммы дополнительный заголовок с адресом). Иногда это недопустимо.
Более внятный вариант -
натирование. Примерная схема на иллюстрации.
Подобная схема часто реализуется при балансировке нагрузки при помощи решений вроде F5. Здесь используется Destination NAT пакетов от клиента к серверу и Source NAT пакетов от сервера к клиенту. Весь трафик от S2 надо будет направить через S1, это может потребовать поднятия какого-либо (например, GRE) туннеля. Также необходимо учесть, что IP-адреса могут использоваться внутри L7-протокола (наиболее известный случай - FTP), это может поднять новые вопросы.
Вообще говоря, ваша задача - широкое минное поле для экспериментов.
Сложный
Простой
