Como facer que AWS inicie un túnel Site-to-Site VPN
A acción de inicio e a acción de tempo de espera DPD responden preguntas distintas. Configure a que fai que AWS inicie e despois comprobe o enderezo do par e a ruta da aplicación.
Por defecto, unha VPN Site-to-Site de AWS espera a que o customer gateway inicie a negociación. Ese defecto é un axuste, non unha lei, e o axuste chámase Startup action. Antes de recorrer a el, separe dúas preguntas que se confunden constantemente: quen establece o túnel e se os paquetes que lle importan teñen unha ruta a través del. Só a primeira vive nas opcións do túnel.
Separe a acción de inicio da acción de tempo de espera DPD
Dúas opcións por túnel gobernan dous acontecementos distintos, e configurar unha non di nada da 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 AWS debe levantar un túnel novo ou modificado, elixa start. Se AWS tamén debe reiniciar a negociación tras un tempo de espera DPD, configure restart para ese acontecemento por separado. Ningunha das dúas é unha política de reintentos da aplicación, e ningunha é un intervalo de recambio de chaves: DPD comproba se o par está vivo, mentres que o recambio de chaves substitúe as security associations dun túnel activo.
Unha aplicación que esgota o tempo mentres o túnel segue informando up ten un problema de ruta de datos. Acortar o temporizador DPD non o arranxará e pode engadir axitación que despois terá que explicar.
Comprobe que AWS ten onde enviar a negociación
A iniciación desde o lado de AWS só funciona con IKEv2, e AWS necesita o enderezo público do customer gateway para saber onde enviar a proposta. O caso que doe é un recurso customer gateway autenticado con certificado creado sen enderezo: a documentación de AWS describe crear un recurso customer gateway novo co enderezo e despois modificar a conexión VPN para que apunte a el.
Un certificado demostra quen é o par. Non lle di a AWS onde está o par, e son dous requisitos distintos. Por iso a solución é un recurso customer gateway novo e non un certificado novo. Cambiar o certificado deixa a AWS co mesmo destino ausente.
Se o customer gateway está detrás de NAT, AWS tamén necesita un responder identity configurado, IDr, para que a identidade do par coincida co que espera o dispositivo. Confirme ese valor e a ruta de cortalumes que admite tráfico IKE antes de culpar a opción que acaba de cambiar. Escoller start non pode facer que un par inalcanzable ou mal identificado acepte unha proposta.
Aplique o cambio a un túnel e espere unha interrupción
Unha conexión VPN ten dous túneles con opcións independentes, así que confirme cal está editando polo seu enderezo exterior. AWS permite modificar un túnel á vez, e a conectividade polo túnel seleccionado pode interromperse durante varios minutos.
- Seleccione a conexión Site-to-Site VPN e abra Modify VPN tunnel options.
- Escolla o túnel polo enderezo IP exterior e confirme a súa versión de IKE e o recurso customer gateway.
- Estableza as accións de inicio e DPD que realmente quere e logo garde nunha ventá que controle.
- Confirme que o túnel modificado se establece e revise o outro túnel e o enrutamento antes do seguinte cambio.
Un comportamento merece atención antes do mantemento. Coa iniciación de AWS activada non hai tempo de espera: AWS segue intentándoo ata que o túnel sobe, e reinicia cando o customer gateway envía unha mensaxe delete-SA. Se baixa o par a propósito, AWS seguirá chamando e os rexistros do par mostrarao.
Verifique a ruta da aplicación, non só o estado do túnel
Un túnel que informa up non é o mesmo ca unha solicitude que funciona. Unha función Lambda conectada a unha VPC segue necesitando unha ruta de subnet cara ao prefixo do cliente, regras de security group e network ACL que permitan o tráfico, resolución de nomes que devolva o enderezo correcto e unha ruta de volta no lado do cliente.
Probe unha vez cunha solicitude real desde o contexto da aplicación e logo lea os flow logs se falla. O tráfico keepalive é unha opción lexítima cando a iniciación de AWS está desactivada e un túnel inactivo necesita paquetes para manterse, pero debería ser unha decisión de monitorización que poida nomear, non un bucle de ping sen explicación atornillado a unha función.
Escolla primeiro quen establece o túnel e logo diagnostique o fallo restante na súa propia capa. A documentación de AWS sobre a iniciación cobre os requisitos de enderezo, identidade e reintentos con máis detalle ca as pistas da consola.