В настоящее время мы запускаем функции AWS Lambda в VPC и, например, уже настроили пиринговое соединение с MongoDB Atlas, чтобы наши AWS Lambda в VPC взаимодействовали с нашей базой данных, размещенной в MongoDB Atlas.
Теперь возникло требование, чтобы определенная служба в нашем VPC, которую мы запускаем с помощью AWS Lambda и которая также работает в том же VPC, имела доступ к локальной сетевой функции/хосту через VPN. Кроме того, эта сеть должна иметь возможность отвечать на сообщения этой службе, поэтому я предполагаю, что необходимо соединение site-to-site.
Клиент предоставил нам параметры первой фазы IKE, параметры второй фазы IKE (IPSEC), свои локальные IP-адреса одноранговых узлов, принятые порты связи VPN и локальные домены шифрования.
Теперь они запрашивают наши удаленные IP-адреса и удаленные домены шифрования.
Вопрос 1: Осуществимо ли то, чего мы пытаемся достичь, на AWS в VPC (я читаю противоречивые сообщения по этому поводу.
вопрос 2: Правильно ли я понимаю, что инициирование туннеля должно происходить со стороны клиента, а затем мы используем опрос сетевого мониторинга для поддержания активности туннеля?
решение1
По вопросу 1.
Предположим, вы имеете в виду возможность подключения через VPN на основе IPSec для безопасного подключения к ресурсам, расположенным за пределами AWS. Ответ — да. Однако собственная реализация AWS имеет некоторые ограничения. Первое — невозможно указать какие-либо аспекты параметров конфигурации фазы 1 или фазы 2. Вместо этого AWS предоставляет вам возможность загружать предварительно настроенные параметры для ряда производителей, а также предоставляет несколько хороших общих примеров.
Вот некоторые хорошие ресурсы:
Управляемые VPN-подключения AWS- предоставляет подробную информацию о сервисе AWS VPN Gateway
Ваш клиентский шлюз- предоставляет информацию о необходимых настройках на устройстве за пределами AWS
По вопросу 2.
Это правда, если туннель по какой-то причине падает, сторона AWS не может его инициировать (это ОЧЕНЬ раздражающее ограничение, если вы меня спросите). Однако есть способы обойти это. Некоторые устройства поддерживают отправку пакетов поддержки активности для поддержания туннеля. Например, Cisco ASA могут использовать функцию IP SLA для отправки сообщений SLA по туннелю для поддержания его работоспособности. Выдержка изпример конфигурации ASA:
Чтобы поддерживать туннель в активном или постоянном состоянии, ASA необходимо отправлять трафик в подсеть, определенную в acl-amzn. Мониторинг SLA можно настроить на отправку пингов в пункт назначения в подсети, и он будет поддерживать туннель активным. Этот трафик необходимо отправлять в цель, которая вернет ответ. Это можно вручную проверить, отправив пинг в цель с ASA, полученный из внешнего интерфейса. Возможным местом назначения для пинга является экземпляр в VPC. Для избыточности несколько мониторов SLA можно настроить на несколько экземпляров для защиты от единой точки отказа.
Или вы можете просто настроить систему на одной стороне так, чтобы она периодически отправляла пинг — с помощью задания cron или запланированной задачи.
Другой вариант, однако, заключается в развертывании собственного шлюза IPSec в AWS - либо запущенного на самом экземпляре, либо на другом экземпляре, затем вы можете обновить таблицу маршрутизации в своей подсети для маршрутизации к подсетям вне AWS через этот экземпляр. Это дает вам больше контроля над настройками и поведением IPSec - но, возможно, более сложное в управлении по сравнению с нативным сервисом AWS.