Постановка задачи
У меня есть требование для плана обеспечения непрерывности бизнеса с использованием AWS Cloud VPC со следующими требованиями:
Собственные сервисы / функции AWS напрямую не помогают
Site2Site VPN - Чтобы удовлетворить эти требования, сеть AWS site-to-site VPN Transit выходит за рамки области применения, поскольку она не допускает перекрытия диапазонов IP-адресов.
Переходя к косвенному способу решения проблемы перекрытия диапазонов IP-адресов, в документации AWS есть резервный план VPN типа «сеть-сеть», но он предназначен для сценария аварийного переключения, и мне нужно, чтобы все удаленные облака могли быть подключены в любое время, т.е. всегда активны.
Транзитный шлюз - AWS Transit Gateway не помогает, так как в идеале не допускает перекрытия диапазонов IP-адресов в мультиоблачных сетях.
Существует способ выполнить сегментацию маршрута, то есть разделение пути маршрутизации для отдельной комбинации взаимосвязанных облаков, используя несколько таблиц маршрутов в транзитном шлюзе, но этот подход требует такой сегментации с использованием подключения транзитного шлюза, и AWS VPC не может иметь более одного подключения. .
Кроме того, даже если мы сделаем что-то подобное, возможно, мы будем использовать программную VPN на экземплярах EC2 (не уверен, если это возможно), я не уверен, сможем ли мы легко подключиться из каждой рабочей области и переключиться на все разные облака, потому что таблица маршрутов подсети AWS VPC разработчика не может иметь перекрывающихся диапазонов IP-адресов в Назначении.
Мой подход к решению
Мой сетевой план
В той же подсети я думал об использовании подхода IPSec VPN на основе программного обеспечения, т.е. в одном случае на EC2 будет служба VPN, такая как strongswan и правила Iptable для SNAT. Этот подход основан на ответе службы поддержки AWS на Настройте NAT для трафика VPN.
Для каждого облака / центра обработки данных будет настроен экземпляр EC2 с программным IPSec VPN и правилами IPtable.
На удаленной стороне также будет шлюз для VPN, как при спаривании AWS VGW и клиентского шлюза.
Чтобы трафик передавался из рабочей области в правое удаленное облако с помощью VPN, мне нужно сделать запись в таблице маршрутов подсети с пунктом назначения в качестве диапазона IP-адресов удаленного облака и цели в качестве идентификатора eni экземпляра VPN EC2.
Проблема с этим подходом Опять же, для удаленных облаков с перекрывающимися IP-адресами я не могу иметь запись в таблице маршрутов подсети AWS VPC разработчика.
Чтобы решить эту проблему, Я думал о том, чтобы сделать что-то вроде манипулирования диапазоном IP-адресов, при котором я буду полностью создавать или нереальные диапазоны IP-адресов для каждого перекрывающегося удаленного облака, то есть для облака с реальным диапазоном IP-адресов 192.168.xy / 16 нереальным будет 10.10. pq / 16.
После этого у меня будет отдельный VPN-сервер EC2 для каждого из этих удаленных облаков. Тогда для маршрута для любого удаленного облака запись в таблице маршрутов будет иметь вид 10.10.p.q / 16 в качестве пункта назначения и идентификатор eni VPN-сервера EC2 в качестве цели.
На сервере EC2 VPN у нас будет настройка правил Iptable, которая будет делать что-то вроде PREROUTING DNAT и POSTROUTING SNAT для пересылки только IP, как показано на этом рисунке. stackoverflow Q / A.
Разработчик рабочих областей должен знать соответствие между нереальным и реальным IP-адресами и отправлять трафик с использованием нереального IP. Правила Iptables для VPN-сервера EC2 необходимо будет обновить с помощью пользовательских сценариев, чтобы это сопоставление постоянно обновлялось с помощью последнего сопоставления.
Я не уверен в правильности и эффективности описанного выше подхода.
Другая проблема, связанная с моим вышеупомянутым подходом
Это также вызывает сомнения в том, что даже если я подключаюсь к экземплярам с определенными IP-адресами в удаленном облаке, но как насчет доступа к другим облачным службам, таким как бессерверные функции или apis, или управляемые / абстрактные службы, такие как DB / LB.
Хотя это можно сделать, отправив трафик с помощью IGW в VPC разработчика или подключившись к хосту-бастиону в удаленном облаке.
Другой подход, который я искал в Интернете настраивает пользовательскую сеть наложения мультиоблака, которая кажется сложной задачей.
Я также не уверен, могут ли VPN с открытым исходным кодом, такие как OpenVPN или pfsense, например брандмауэр / сетевое программное обеспечение, помочь с некоторыми из их собственных функций для решения моей исходной проблемы.
Я получил все свои знания о сетях или VPN, работая только в облаке AWS, и я не очень хорошо разбираюсь в сетевых технологиях в целом в компьютерных науках.
Пожалуйста, помогите с этими проблемами.