Я работаю в группе разработчиков, которые географически распределены, в основном по всему штату Калифорния, но некоторые ключевые члены также должны часто путешествовать.
Мы очень сильно полагаемся на API сторонних поставщиков для большинства наших подсистем (не можем понять, кто это и что они делают). Однако сторонние организации довольно строги в отношении доступа к сети и не имеют понятия о песочнице разработки. Доступ ограничен 2, 3 номерами IP и все. После того, как мы учтем наши производственные серверы, у нас останется один или два IP-адреса для нашей команды разработчиков, что по-прежнему проблематично, поскольку у людей меняются домашние IP-адреса, люди путешествуют, у нас более двух разработчиков и т. Д.
Сторонние организации не разрешают использование широких IP-адресов. Они также не позволят использовать службы динамического типа DNS. Также нет простой консоли для обмена IP-адресами на лету (например, если IP-адрес разработчика меняется дома или они находятся в пути).
Поскольку никто из нас не является экспертом в области глубоких сетей, мне интересно, какие у нас есть варианты?
Существуют ли сторонние хосты для VPN? Обычно я думаю о VPN как о механизме для получения доступа к домашнему офису, но это будет сторонняя VPN, к которой мы все будем подключаться, и мы будем регистрировать это как источник IP с нашей третьей стороной.
Мы рассмотрели возможность использования Amazon EC2 для эффективного размещения среды разработки для каждого разработчика и ее использования для подключения. Однако Amazon дает вам столько статических IP-адресов (я полагаю, 5?), Так что это будет лишь временное решение, пока наша команда не сократит количество IP-адресов в Amazon.
Это были единственные жизнеспособные мысли, которые у меня были, но, опять же, я далек от сетевого парня. Пытался найти похожие темы, но я даже не уверен, что знаю правильный язык, чтобы искать.
Я могу придумать два решения - одно для слоя 3 и одно для слоя 7.
Я бы подумал о том, чтобы разместить где-нибудь сервер со статическим IP-адресом и разместить там что-то вроде OpenVPN. Вы можете развернуть конфигурацию OpenVPN, которая заставляет любой доступ к API маршрутизироваться через OpenVPN на размещенный сервер со статическим IP-адресом, после чего вы можете выполнить NAT на IP-адрес этого сервера.
В качестве альтернативы вы можете запустить прокси-сервер уровня 7 на размещенном сервере (что-то вроде Squid - я предполагаю, что ваш API доступен через HTTP) и направлять запросы от ваших разработчиков через этот прокси-сервер.
Редактировать:
Использование прокси-сервера уровня 7 означает, что вам не нужно устанавливать какое-либо клиентское программное обеспечение для разработчиков, если их существующие инструменты могут справиться с указанием прокси-сервера HTTP. Однако вы, вероятно, не хотите, чтобы весь их доступ маршрутизировался через этот удаленный прокси-сервер, поэтому вам следует использовать такие функции, как файл автоконфигурации прокси или локальные прокси-серверы, чтобы перенаправлять только соответствующие запросы API на размещенный прокси. Некоторые браузеры не поддерживают использование SSL между клиентом и прокси, поэтому запросы разработчиков будут передаваться через Интернет в незашифрованном виде.
Использование решения уровня 3 устраняет необходимость настраивать браузеры разработчиков с использованием прокси-сервера HTTP, но означает, что им потребуется какой-то установленный и работающий клиент VPN. Их запросы будут зашифрованы между сервером VPN и их клиентским компьютером, однако это может быть совершенно спорным вопросом, если запросы между размещенным сервером VPN и серверами API выполняются в открытом виде.
Похоже, вам нужно решение NAT. Вы можете создать VPN-туннель, а затем принудительно передать данные в API через NAT. Таким образом, все они будут выглядеть так, как будто исходят с одного IP-адреса. Настройка будет выглядеть примерно так: Разработчики ----- VPN ----- частная подсеть --- NAT --- Внешний IP-адрес