Назад | Перейти на главную страницу

Как обойти белый список IP-адресов при использовании стороннего API?

Мы используем службу, API которой отклоняет запросы, если исходный IP-адрес не был ранее внесен в белый список. Они дают нам только 3 слота, что является проблемой, потому что у нас более 3 машин, которым необходимо использовать API.

Каков наиболее распространенный способ решения этой проблемы?

Примечание: Я не пытаюсь что-либо сделать против Условий использования стороннего API. Мы используем ResellerClub и я связался с ними, чтобы попросить больше слотов, но они ответили:

Я прошу вас любезно направить ваши серверы на несколько наборов IP-адресов.

Отсюда этот вопрос.

Мысли:

Я думал, что мы могли бы решить проблему, запустив своего рода прокси, который действует как посредник. Вместо того, чтобы делать запросы API к стороннему лицу, мы отправляем их на наш прокси-сервер, который отправляет запрос стороннему поставщику, так что все запросы кажутся им исходящими с одного IP-адреса в их глазах. Есть ли распространенное программное обеспечение для этого? Это кажется проще, чем приведенные ниже мысли, но я ошибаюсь?
Следует ли мне обратить внимание на использование «экземпляра NAT»? например http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html . Выглядит сложно - разве нет более простого решения? (Жалко запускать дополнительный экземпляр с повышенной сетевой сложностью).
Поскольку мы используем Docker, могли бы Ткать быть актуальным?
Можно ли подключить статический IP-адрес к шлюзу VPC? Я видел, что это возможно с помощью AWS Storage Gateway (источник) - не уверен насчет обычного vpc igw?

Наша архитектура: Мы используем AWS, и наши экземпляры в VPC работают за ELB. Мы часто запускаем новые экземпляры, не зная заранее IP-адреса. У нас одинаковое программное обеспечение на всех машинах. На машинах работает CoreOS, а наше приложение работает в контейнерах Docker.

Достаточно распространенная инфраструктура - это инфраструктура, в которой ни один из реальных серверов приложений не имеет общедоступных IPv4-адресов, они будут находиться в диапазоне частной сети RFC 1918 за балансировщиком нагрузки, и любой исходящий запрос, который они делают, будет либо:

маршрутизируется через шлюз NAT, создавая видимость единого исходного IP-адреса
должен выполняться через прокси-сервер, который соединяет частный диапазон IP-адресов и большую часть Интернета.

Я думал, что опубликую обновление, так как проект теперь успешно завершен с использованием экземпляра NAT.

Следует ли мне обратить внимание на использование «экземпляра NAT»? Выглядит сложно - разве нет более простого решения?

Теперь, когда экземпляр NAT настроен, первоначальное ощущение сложности прошло, и на самом деле он кажется довольно простым - даже чище, чем на самом деле (потому что принудительное использование частных подсетей повышает безопасность).

Официальные инструкции по настройке экземпляра NAT от AWS работали хорошо: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html . Мы использовали AMI, предоставляемый Amazon для загрузки инстанса NAT. Пройдя через этот процесс, я понял, насколько это «отраслевой стандарт», может быть, даже «лучшая практика».

Недостатки:

Экземпляр NAT становится единственной точкой отказа. Поскольку весь внешний трафик, исходящий с наших веб-серверов, проходит через него, в случае сбоя экземпляры не смогут подключиться к Интернету для получения обновлений программного обеспечения, вызова внешних API-интерфейсов (например, платежных шлюзов), и мы не сможем подключиться к SSH. экземпляры.
Использование дополнительной машины стоит денег и требует большего обслуживания. (t2.small не очень дорого, а стандартный AMI не требует модификации, поэтому не требует большого обслуживания).
У экземпляров будет более медленное внешнее сетевое соединение. (Я пока не заметил разницы).
Мы не можем напрямую подключиться к экземплярам по SSH, нам нужно пройти через экземпляр NAT (с помощью агента SSH). Звучит хуже, чем есть на самом деле. Если вы потратите несколько минут на редактирование .ssh/config и читайте дальше "ProxyCommand"вы можете сделать вещи на 100% прозрачными, чтобы просто ssh server1 работает.
Мы больше не можем тестировать конкретный сервер в кластере, используя его общедоступный IP-адрес (или имея DNS-запись для конкретной машины). Это то, что можно быстро преодолеть. Обходной путь, если вам действительно нужно убедиться, что вы попали в одну машину, - это создать новый ELB и поместить в пул экземпляров только ту машину, на которую вы хотите настроить таргетинг.