В настоящее время мы выполняем функции AWS Lambda в VPC и, например, уже настроили пиринговое соединение с MongoDB Atlas, чтобы наши AWS Lambda в VPC могли связываться с нашей базой данных, размещенной в MongoDB Atlas.
Теперь возникло требование, согласно которому конкретная служба в нашем VPC, которую мы запускаем с помощью AWS Lambda и которая также работает в том же VPC, должна иметь доступ к локальной сетевой функции / хосту через VPN. Кроме того, эта сеть должна иметь возможность отвечать на сообщения этой службы, поэтому я предполагаю, что требуется соединение типа "сеть-сеть".
Клиент предоставил нам параметры фазы 1 IKE, параметры фазы 2 IKE (IPSEC), их локальные IP-адреса одноранговых узлов, принятые порты связи VPN и локальные домены шифрования.
Теперь они запрашивают наши удаленные IP-адреса одноранговых узлов и удаленные домены шифрования.
Вопрос 1: Это то, чего мы пытаемся достичь на AWS в VPC (я читаю противоречивые сообщения об этом.
вопрос 2: Правильно ли я предполагаю, что инициирование туннеля должно происходить со стороны клиента, и что затем мы используем опрос сетевого мониторинга, чтобы туннель оставался активным?
По вопросу 1.
Предполагая, что вы имеете в виду возможность подключения через VPN на основе IPSec для безопасного подключения к ресурсам, расположенным за пределами AWS. Ответ положительный. Однако встроенная реализация этого AWS имеет некоторые ограничения. Во-первых, невозможно указать какие-либо аспекты настроек конфигурации фазы 1 или фазы 2. Вместо этого AWS предоставляет вам возможность загружать предварительно настроенные параметры для ряда производителей, а также предоставляет несколько хороших общих примеров.
Вот несколько хороших ресурсов:
AWS Managed VPN-подключения - предоставляет подробную информацию о сервисе 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.