Unha Elastic IP de EC2 non é o enderezo VPN privado da instancia

A instancia ten un enderezo privado, a Elastic IP está asociada a el e engádese unha ruta para ese /32 público á VPN coa esperanza de que ambos se convertan no mesmo. Non o fan. Unha Elastic IP é unha tradución realizada fóra do convidado, pola pasarela de internet, sobre o tráfico que toma a ruta de internet. O sistema operativo do convidado nunca ve ese enderezo configurado nunha interface. Engadila a unha interface de túnel non reproduce a tradución augas arriba e crea unha segunda identidade, en conflito, para a mesma máquina.

Dous enderezos, unha instancia

A interface de rede da instancia ten un enderezo privado dentro da VPC, e ese é o enderezo que coñece o convidado. A Elastic IP está asociada á mesma interface pero vive no lado público da asignación.

Todo o que chega á instancia por internet chega traducido ao enderezo privado. Todo o que a instancia envía a internet sae coa Elastic IP como orixe, de novo por esa tradución.

Dentro do convidado existe un enderezo. Fóra existen dous. Esa asimetría explica a maior parte da confusión neste eido. O convidado non pode configurar o que traduce a pasarela. Só pode responder no enderezo que realmente ten.

Que fai realmente a pasarela de internet

A documentación de AWS sobre a pasarela de internet describe o arranxo: a instancia coñece o seu enderezo IPv4 privado e a pasarela proporciona a tradución correspondente a IPv4 pública ou Elastic IP para o tráfico da ruta de internet.

Iso é tradución de enderezos de rede, non un alias. A asignación manténa a pasarela, está ligada á asociación e só se aplica aos paquetes que a atravesan. Quitade a asociación e a identidade pública desaparece sen que o convidado note nada.

Por iso un paquete VPN privado dirixido ao /32 público non se reinterpreta como un paquete privado cara ao enderezo local do convidado. O paquete segue a ruta coa que coincide, que o envía á pasarela de internet, e o comportamento da pasarela depende de que a ruta estea permitida en ambos os sentidos.

Por que falla o truco da interface de túnel

Asignar a Elastic IP a unha interface de túnel pide ao convidado que trate un enderezo público como local. Agora dúas cousas reclaman o mesmo enderezo: a tradución da pasarela na ruta de internet e a interface local dentro do túnel. O tráfico de retorno non ten unha resposta coherente sobre cal se aplica.

Mesmo cando parece funcionar, o deseño ocultou a verdadeira pregunta. Os clientes ou chegan ao enderezo privado polo túnel ou chegan ao punto final público por internet, e as dúas rutas teñen grupos de seguridade distintos, rexistro distinto e modos de fallo distintos.

O enderezo nunca foi o problema. A selección de ruta si.

Tres obxectivos, tres deseños

Se o obxectivo é un punto final VPN público, a Elastic IP é a ferramenta correcta: os pares remotos conéctanse a ela por internet e o transporte cifrado remata na instancia. O tráfico interno da aplicación usa despois o enderezo privado.

Se o obxectivo é o acceso privado á aplicación, o destino é o enderezo privado ou un nome DNS privado que resolva a el, e a ruta VPN, o grupo de seguridade e a ruta de retorno deben coincidir todos. A Elastic IP non aparece nese deseño en absoluto.

Se o obxectivo é unha identidade de saída pública estable para os usuarios de VPN, iso é un deseño NAT no lado de saída, non un enderezo no túnel do cliente. Tres obxectivos que soan parecidos producen tres diagramas distintos, e só un implica poñer unha Elastic IP nun lugar novo.

Verificade a ruta que escollechedes

Para o acceso privado, confirmade que a ruta VPN cobre o prefixo privado, que a táboa de rutas da VPC devolve o tráfico ao túnel, que o grupo de seguridade permite a orixe do cliente e que a devasa do propio cliente permite a resposta. Logo probade unha petición real en lugar dun ping.

Para o acceso público, confirmade a saída a internet do cliente, o enrutamento da entrada pública e a súa política de seguridade. Que un cliente VPN poida chegar a un punto final público polo túnel depende das regras de saída e da devasa do túnel, non da asociación da Elastic IP.

Se un nome de host público ten que funcionar desde ambos os lados, usade un deseño DNS que responda co enderezo privado para os clientes VPN e co enderezo público para todos os demais, e mantede o certificado válido para o nome en lugar de para o enderezo. Orde de traballo: nomeade o obxectivo, escollede o enderezo que lle pertence e logo verificade rutas, política e unha petición.