No momento, estamos executando funções AWS Lambda em uma VPC e, por exemplo, já temos uma configuração de conexão de peering com o MongoDB Atlas para que nossos AWS Lambda dentro da VPC se comuniquem com nosso banco de dados hospedado no MongoDB Atlas.
Agora surgiu um requisito de que um serviço específico em nosso VPC que acionamos por um AWS Lambda e que também é executado no mesmo VPC tenha que acessar uma função/host de rede local por meio de VPN. Além disso, essa rede precisa ser capaz de responder às mensagens desse serviço, portanto, presumo que seja necessária uma conexão site a site.
O cliente nos forneceu os parâmetros IKE da fase um, os parâmetros IKE da fase dois (IPSEC), seus endereços IP de pares locais, as portas de comunicação VPN aceitas e os domínios de criptografia locais.
Eles agora estão solicitando nossos endereços IP de pares remotos e domínios de criptografia remotos.
Questão 1: é o que estamos tentando alcançar na AWS em uma VPC (estou lendo postagens conflitantes sobre isso.
Questão 2: Estou correto ao assumir que o início do túnel terá que acontecer do lado do cliente e que então usaremos a pesquisa de monitoramento de rede para manter o túnel ativo?
Responder1
Em relação à questão 1.
Supondo que você esteja se referindo à capacidade de conexão por meio de uma VPN baseada em IPSec para conectar-se com segurança a recursos localizados fora da AWS. A resposta é sim. No entanto, a implementação nativa da AWS tem algumas restrições. A primeira é que não é possível especificar nenhum aspecto das definições de configuração da fase 1 ou da fase 2. Em vez disso, a AWS oferece a capacidade de baixar configurações pré-configuradas para vários fabricantes, mas também fornece alguns bons exemplos genéricos.
Alguns bons recursos são:
Conexões VPN gerenciadas pela AWS- fornece detalhes sobre o serviço AWS VPN Gateway
Seu portal de clientes- fornece informações sobre as configurações necessárias no dispositivo fora da AWS
Em relação à questão 2.
Isso é verdade, se o túnel cair por algum motivo, o lado da AWS não poderá iniciá-lo (esta é uma limitação MUITO irritante se você me perguntar). No entanto, existem maneiras de contornar isso. Alguns dispositivos suportam o envio de pacotes keep alive para manter o túnel ativo. Por exemplo, os Cisco ASA podem fazer uso do recurso IP SLA para enviar mensagens SLA de acordo com o túnel para mantê-lo ativo. Extraído dea configuração ASA de amostra:
Para manter o túnel em um estado ativo ou sempre ativo, o ASA precisa enviar tráfego para a sub-rede definida em acl-amzn. O monitoramento de SLA pode ser configurado para enviar pings para um destino na sub-rede e manterá o túnel ativo. Esse tráfego precisa ser enviado para um alvo que retornará uma resposta. Isto pode ser testado manualmente enviando um ping ao alvo do ASA originado da interface externa. Um possível destino para o ping é uma instância dentro da VPC. Para redundância, vários monitores SLA podem ser configurados para diversas instâncias para proteção contra um único ponto de falha.
Ou você pode simplesmente organizar um sistema de um lado para enviar periodicamente um ping - por meio de um cron job ou tarefa agendada.
Outra opção, no entanto, é implantar seu próprio gateway IPSec na AWS - seja em execução na própria instância ou em outra instância, você pode atualizar a tabela de rotas em sua sub-rede para rotear para as sub-redes fora da AWS por meio desta instância. Isso permite mais controle sobre as configurações e o comportamento do IPSec, mas é indiscutivelmente mais complexo de gerenciar em comparação com o serviço nativo da AWS.