Исходящий прокси-сервер с использованием нескольких общедоступных IP-адресов в EC2
У нас есть несколько серверов бэкэнда в виде экземпляров EC2, расположенных в частной подсети в AWS VPC, которым необходимо взаимодействовать со сторонним API. Этот API ограничивает количество запросов, которые мы можем отправлять, на основе исходного IP-адреса, и при масштабировании нашей настройки мы начали достигать ограничений на IP-адрес шлюза NAT, который используется для всего исходящего трафика.
Поэтому я хочу настроить прокси-сервер для исходящего трафика с несколькими подключенными EIP. Для тестирования я сейчас использую экземпляр Amazon Linux 2 с двумя ENI и двумя EIP к каждому. Внутренние серверы открывают SSH-туннель к исходящему прокси-серверу и сопоставляют сторонний API с локальным портом, запись в файле хостов серверов перенаправляет весь трафик с этого имени хоста на локальный хост, и эта настройка в целом работает нормально, но исходящий трафик с прокси-сервер всегда использует только первый связанный EIP.
Итак, моя установка выглядит так:
ENI1: eth0
private IP1: 10.0.11.81
private IP2: 10.0.11.82
ENI2: eth1
private IP3: 10.0.11.52
private IP4: 10.0.11.53
original route table:
default via 10.0.11.1 dev eth0
default via 10.0.11.1 dev eth1 metric 10001
10.0.11.0/24 dev eth0 proto kernel scope link src 10.0.11.81
10.0.11.0/24 dev eth1 proto kernel scope link src 10.0.11.52
169.254.169.254 dev eth0
Теперь я хочу иметь возможность указать, какой внутренний сервер использует какой EIP при вызове API через исходящий прокси. Моя первая попытка заключалась в следующем:
- настроить 4 разных пользователей на прокси-хосте
- добавьте правила iptable для каждого пользователя следующим образом:
и т. д. - это работает для двух IP-адресов, которые подключены к основному ENI (т. е. eth0 на машине), но не работает для двух IP-адресов, связанных со вторым ENI (eth1).
- добавление
на утверждение тоже не сработало
Моей следующей попыткой было создать собственные таблицы маршрутизации для каждого IP-адреса и сопоставить их с правилами политики:
- создайте собственную таблицу маршрутов, например для IP3:
default via 10.0.11.1 dev eth1
10.0.11.0/24 dev eth1 proto static scope link src 10.0.11.52
169.254.169.254 dev eth1 scope link
- создайте правило iptables, чтобы отмечать трафик, исходящий от пользователя user3:
-A OUTPUT -m owner --uid-owner 1003 -j MARK --set-xmark 0x3/0xffffffff
- создайте правило для использования пользовательской таблицы маршрутов для всех пакетов, отмеченных 3:
32763: from all fwmark 0x3 lookup ip3
- это опять не работает. пакеты обрабатываются по-разному. все пользователи могут общаться с миром, за исключением пользователя user3 в приведенном выше примере.
Что я делаю не так? Есть ли что-то тривиальное, что мне не хватает, или весь мой подход обречен на провал? Я очень открыт для предложений, как по поводу того, как заставить эту установку работать, так и по альтернативным подходам...
Заранее большое спасибо!
1 ответ
Свяжитесь с организацией, использующей API, и объясните ситуацию. Создание деловых отношений – хорошее начало решения проблемы.
Внедрите IPv6, чтобы уменьшить техническую сложность. AWS предоставит вам /64 для каждой подсети общедоступного пространства, что позволит осуществлять прямую связь между вашими экземплярами и API. Уникальный адрес каждого экземпляра дает понять, что вы действительно масштабируетесь. Попросить предоставить вашим сетям более высокую квоту становится проще, поскольку все они находятся в /56 вашего VPC.