Постановка задачи
У меня есть потребность в плане обеспечения непрерывности бизнеса с использованием AWS Cloud VPC со следующими требованиями:
- В частной подсети AWS VPC нашего разработчика у нас будут рабочие пространства (т. е. защищенный AWS Desktop-as-a-Service) для каждого разработчика.
- Из этих рабочих пространств каждый разработчик может подключаться к разным удаленным облакам с помощью VPN, то есть к публичным облакам GCP/AWS/Azure или даже к локальным центрам обработки данных. Эти разные удаленные центры обработки данных или публичные облака могут иметь перекрывающиеся диапазоны IP-адресов, и мы не имеем никакого контроля над управлением этими диапазонами IP-адресов.
- Разработчик может легко переключаться и подключаться между различными облаками из рабочего пространства с помощью VPN
Собственные сервисы/функции AWS не помогают напрямую
VPN-соединение между сайтами- Для удовлетворения этих требований транзитная сеть AWS site-to-site VPN выходит за рамки, поскольку она не допускает перекрытия диапазонов IP-адресов.
Если пойти косвенным путем решения проблемы перекрытия диапазонов IP-адресов, в документации AWS есть избыточный план site-to-site VPN, но он предназначен для сценария отказоустойчивости, а мне нужно, чтобы все удаленные облака могли быть подключены в любое время, т. е. были всегда активны.
Транзитный шлюз- AWS Transit Gateway не помогает, потому что он в идеале не допускает перекрытия диапазонов IP-адресов в многооблачных сетях.
Есть способ сделать сегментацию маршрутов, т. е. разделение пути маршрутизации для отдельной комбинации взаимосвязанных облаков, используя несколько таблиц маршрутизации в Transit Gateway, но этот подход требует такой сегментации с использованием присоединения Transit Gateway, а AWS VPC не может иметь более одного присоединения.
Кроме того, даже если мы сделаем что-то подобное, возможно, используя программный VPN на экземплярах EC2 (не уверен, возможно ли это), я не уверен, сможем ли мы легко подключиться из каждой рабочей области и переключиться на все разные облака, потому что таблица маршрутизации подсети AWS VPC разработчика не может иметь перекрывающихся диапазонов IP-адресов в пункте назначения.
Мой подход к решению
Мой сетевой план
В той же подсети я думал об использовании программного подхода IPSec VPN, т.е. в одном экземпляре на EC2 будет VPN-сервис вроде strongswan и правила Iptable для SNAT. Этот подход вдохновлен ответом службы поддержки AWS наНастройте NAT для VPN-трафика.
Для каждого облака/центра обработки данных будет настроен экземпляр EC2 с программным IPSec VPN и правилами IPtable.
На удаленной стороне также будет шлюз для VPN, как и для AWS VGW и сопряжения клиентского шлюза.
Чтобы трафик шел из Workspace в нужное удаленное облако с использованием VPN, мне нужно сделать запись в таблице маршрутизации подсети с Destination в качестве диапазона IP-адресов удаленного облака и Target в качестве eni id экземпляра VPN EC2.
Проблема с этим подходомопять же, для удаленных облаков с перекрывающимися IP-адресами я не могу иметь запись в таблице маршрутизации подсети AWS VPC разработчика.
Для решения этой проблемы, я думал сделать что-то вроде манипуляции диапазоном IP, в котором у меня будут полностью выдуманные или нереальные диапазоны IP для каждого перекрывающегося удаленного облака, т. е. для облака с реальным диапазоном IP как 192.168.xy/16, нереальным будет 10.10.pq/16.
После этого у меня будет отдельный сервер EC2 VPN для каждого из этих удаленных облаков. Тогда для маршрута для любого удаленного облака запись в таблице маршрутизации будет 10.10.pq/16 в качестве назначения и eni id сервера EC2 VPN в качестве цели.
На сервере EC2 VPN у нас будет настройка правил Iptable, которая будет делать что-то вроде PREROUTING DNAT и POSTROUTING SNAT для пересылки только IP, как показано в этомВопросы и ответы по StackOverflow.
Разработчику в рабочих пространствах необходимо знать сопоставление между нереальными и реальными IP-адресами и отправлять трафик с использованием нереального IP-адреса. Правила Iptables сервера EC2 VPN должны быть обновлены с помощью пользовательских скриптов, чтобы это сопоставление поддерживалось в актуальном состоянии с учетом последних сопоставлений.
Я не уверен в правильности или эффективности моего вышеизложенного подхода.
Еще одна проблема, вытекающая из моего подхода, изложенного выше.
Также возникает сомнение, что даже если я подключаюсь к экземплярам с определенными IP в удаленном облаке, но как насчет доступа к другим облачным сервисам, таким как Serverless-функции или API или управляемые/абстрактные сервисы, такие как DB/LB.
Хотя это можно сделать, отправив трафик с помощью IGW в VPC разработчика или подключившись к бастионному хосту в удаленном облаке.
Другой подход, который я искал в интернетенастраивает пользовательскую многооблачную сеть наложения, которая кажется пугающей или ракетной наукой.
Я также не уверен, что VPN с открытым исходным кодом, такие как OpenVPN или pfsense, как брандмауэр/сетевое программное обеспечение, могут помочь с некоторыми из их собственных функций, чтобы решить мою изначальную проблему.
Все свои знания в области сетевых технологий и VPN я получил, работая исключительно в облаке AWS, и в компьютерной науке я не очень хорошо разбираюсь в сетевых технологиях в целом.
Помогите, пожалуйста, с этими задачами.