Como fazer o AWS iniciar um túnel Site-to-Site VPN
A ação de inicialização e a ação de timeout do DPD respondem a perguntas diferentes. Defina a que faz o AWS iniciar e depois verifique o endereço do par e a rota da aplicação.
Por predefinição, uma VPN Site-to-Site da AWS espera que o customer gateway inicie a negociação. Essa predefinição é uma configuração, não uma lei, e a configuração chama-se Startup action. Antes de recorrer a ela, separe duas perguntas que se confundem constantemente: quem estabelece o túnel e se os pacotes que lhe interessam têm uma rota através dele. Só a primeira vive nas opções do túnel.
Separe a ação de inicialização da ação de timeout do DPD
Duas opções por túnel governam dois eventos diferentes, e definir uma não diz nada sobre a outra.
| Event | Option | Useful values |
|---|---|---|
| A new or modified VPN connection needs a tunnel | Startup action | add waits for the peer; start asks AWS to initiate |
| Dead peer detection times out | DPD timeout action | clear ends the session, restart reinitiates, none does nothing |
Se a AWS deve levantar um túnel novo ou alterado, escolha start. Se a AWS também deve reiniciar a negociação após um timeout do DPD, configure restart para esse evento em separado. Nenhuma das opções é uma política de repetição da aplicação, e nenhuma é um intervalo de renovação de chave: o DPD verifica se o par está vivo, enquanto a renovação de chave substitui as security associations num túnel ativo.
Uma aplicação que expira enquanto o túnel ainda reporta up tem um problema no caminho de dados. Encurtar o temporizador do DPD não o resolve e pode acrescentar agitação que terá de explicar mais tarde.
Verifique se a AWS tem para onde enviar a negociação
A iniciação do lado da AWS só funciona com IKEv2, e a AWS precisa do endereço público do customer gateway para saber para onde enviar a proposta. O caso que dói é um recurso customer gateway autenticado por certificado criado sem endereço: a documentação da AWS descreve criar um novo recurso customer gateway com o endereço e depois alterar a ligação VPN para apontar para ele.
Um certificado prova quem é o par. Não diz à AWS onde o par está, e são dois requisitos diferentes. Por isso a solução é um novo recurso customer gateway e não um novo certificado. Trocar o certificado deixa a AWS com o mesmo destino em falta.
Se o customer gateway estiver atrás de NAT, a AWS também precisa de um responder identity configurado, IDr, para que a identidade do par corresponda ao que o dispositivo espera. Confirme esse valor e o caminho da firewall que admite tráfego IKE antes de culpar a opção que acabou de alterar. Escolher start não consegue fazer um par inalcançável ou mal identificado aceitar uma proposta.
Aplique a alteração a um túnel e conte com uma interrupção
Uma ligação VPN tem dois túneis com opções independentes, por isso confirme qual está a editar pelo endereço exterior. A AWS permite alterar um túnel de cada vez, e a conectividade pelo túnel escolhido pode ser interrompida durante vários minutos.
- Selecione a ligação Site-to-Site VPN e abra Modify VPN tunnel options.
- Escolha o túnel pelo endereço IP exterior e confirme a versão de IKE e o recurso customer gateway.
- Defina as ações de inicialização e DPD que realmente quer e depois guarde numa janela que controle.
- Confirme que o túnel alterado se estabelece e verifique o outro túnel e o encaminhamento antes da alteração seguinte.
Um comportamento merece atenção antes da manutenção. Com a iniciação da AWS ativa não há timeout: a AWS continua a tentar até o túnel subir, e reinicia quando o customer gateway envia uma mensagem delete-SA. Se desligar o par de propósito, a AWS continuará a bater, e os registos do par vão mostrá-lo.
Verifique o caminho da aplicação, não apenas o estado do túnel
Um túnel que reporta up não é o mesmo que um pedido que funciona. Uma função Lambda ligada a uma VPC continua a precisar de uma rota subnet para o prefixo do cliente, de regras de security group e network ACL que permitam o tráfego, de resolução de nomes que devolva o endereço certo e de um caminho de retorno do lado do cliente.
Teste uma vez com um pedido real a partir do contexto da aplicação e depois leia os flow logs se falhar. O tráfego keepalive é uma opção legítima quando a iniciação da AWS está desligada e um túnel inativo precisa de pacotes para se manter, mas deve ser uma decisão de monitorização que consiga nomear, não um ciclo de ping inexplicado aparafusado a uma função.
Escolha primeiro quem estabelece o túnel e depois diagnostique a falha restante na sua própria camada. A documentação da AWS sobre a iniciação cobre os requisitos de endereço, identidade e repetição com mais detalhe do que as sugestões da consola.