Я хотел бы использовать сторонний API. Эта третья сторона требует, чтобы я установил VPN-соединение с их сетью. Таким образом, им нужен IP-адрес удаленного узла для установления VPN, а затем внутренний IP-адрес, который они могут занести в белый список.
Мое приложение размещено на Google Cloud Platform, поэтому я хотел бы настроить VPN-туннель и шлюз с помощью Google Cloud VPN. Я собираюсь использовать виртуальную машину GCE для запроса стороннего API через VPN.
Я настроил VPN-шлюз и туннель на основе маршрута (только с одним маршрутом) для стороннего поставщика с помощью Cloud VPN. Консоль GCP подтвердила, что соединение было успешно установлено.
Я также настроил виртуальную машину GCE и назначил ей статический внутренний IP-адрес и статический внешний IP-адрес.
Сторонняя сторона внесла в белый список статический внешний IP-адрес, назначенный моей виртуальной машине.
Мое решение не сработало. Несмотря на то, что VPN успешно подключился, мне не удалось проверить связь с внутренним IP-адресом, предоставленным третьей стороной с моей виртуальной машины GCE.
Проблема в том, что третья сторона утверждает, что зарезервировала все возможные внутренние IP-адреса в своей собственной сети: 172. *, 192. *, 10. *, как бы странно это ни звучало ... Таким образом, они не могут занести в белый список внутренний IP-адрес моей виртуальной машины, который конфликтует с их внутренним диапазоном адресов. Вместо этого они внесли в белый список внешний IP-адрес, назначенный моей виртуальной машине.
Этот подход не сработал, так как я не мог пропинговать их внутренний IP-адрес с моей виртуальной машины.
Как нам это обойти? Я думаю, проблема в том, что когда я использую свою виртуальную машину для запроса их API через VPN, трафик исходит от внутреннего IP-адреса (но они внесли в белый список только мой внешний IP-адрес). Итак, есть ли способ заставить трафик исходить с внешнего IP-адреса моей виртуальной машины при использовании Cloud VPN?
Я изучил настройку собственной VPN на экземпляре виртуальной машины, используя следующие инструкции: Настройте экземпляр как VPN-шлюз. Однако кажется, что даже здесь я сталкиваюсь с той же проблемой конфликта диапазонов внутренних IP-адресов.
Любая помощь будет принята с благодарностью!
Согласно документации GCP, Cloud VPN можно использовать с Сети VPC и унаследованные сети. Для VPC Пользовательский режим рекомендуется, чтобы у вас был полный контроль над диапазонами IP-адресов, используемых подсетями в сети. Насколько я понимаю, использовать внешний IP-адрес с Cloud VPN невозможно.
Как вы упомянули, невозможно использовать диапазон IP-адресов 172., 192., 10.X, не могли бы вы попробовать использовать какой-либо другой диапазон IP-адресов, который является допустимым RFC 1918 Блок CIDR.
10.0.0.0 - 10.255.255.255 (префикс 10/8)
172.16.0.0 - 172.31.255.255 (префикс 172.16 / 12)
192.168.0.0 - 192.168.255.255 (префикс 192.168 / 16)
Надеюсь, не все эти блоки CIDR зарезервированы. Использование экземпляра виртуальной машины в GCP в качестве шлюза VPN создаст ту же проблему, что и получение IP из того же блока IP. Что вы можете сделать, так это попросить стороннюю организацию освободить небольшие сегменты IP-блока и использовать этот IP-блок для создания сети с настраиваемым режимом и использовать его в этом VPN-сенарио.
Однако, если вы хотите использовать Cloud VPN, вам придется использовать один из этих блоков CIDR.
Для этого, если вы хотите, вы можете создать запрос функции для использования внешнего IP-адреса с Cloud VPN, для этого выполните следующие действия. ссылка на запрос функции.