EC2 entre zonas de dispoñibilidade: comprobe o encamiñamento antes dunha VPN

Antes de instalar software VPN entre dúas instancias EC2, responda unha pregunta: están no mesmo VPC? Se o están, a ruta privada xa existe e unha localización entre zonas non o cambia. A maior parte do traballo nesta situación é confirmar que táboa de rutas usa realmente cada subrede e despois descubrir se o fallo era sequera un problema de encamiñamento. Un túnel adoita ser a resposta equivocada a esta pregunta concreta.

Comprobación 1: mesmo VPC ou VPC distintos

Un VPC é rexional e abrangue zonas de dispoñibilidade, mentres que cada subrede pertence exactamente a unha zona. Dúas instancias en zonas distintas dun mesmo VPC seguen dentro do mesmo dominio de encamiñamento privado.

Os VPC distintos nunca obteñen unha ruta privada por compartir unha rexión ou unha etiqueta de zona. Ese caso necesita unha conexión admitida e o seu propio traballo de rutas e permisos, que é unha decisión aparte.

Comprobación 2: que din as táboas de rutas das subredes

Escriba o deseño con valores reais. Un VPC en 10.60.0.0/16 con subredes 10.60.1.0/24 e 10.60.2.0/24 dá ás instancias 10.60.1.10 e 10.60.2.20 unha ruta pola ruta local do VPC.

Despois revise as táboas asociadas a ambas as subredes, non só a que atopou primeiro. Unha ruta de inspección ou de dispositivo máis específica pode anular a ruta base, e o destino da ruta local pode ser substituído en configuracións máis novas. Unha ruta local visible nalgún lugar da consola non demostra que ambas as cargas de traballo a usen.

Use os enderezos e os nomes privados que o VPC asigna realmente. Un enderezo privado non ten que comezar por 10, e inventar un de memoria é como se diagnostica mal unha contorna que funciona.

Comprobación 3: encamiñamento ou autorización

O encamiñamento só leva o paquete ata a interface de rede do destino. O grupo de seguridade do destino aínda debe admitir a orixe e o servizo, as regras de saída da orixe teñen que permitir a petición, e calquera ACL de rede debe permitir ambos os sentidos porque as ACL non gardan estado.

Detrás están a devasa do convidado, a vinculación do oínte e a identidade propia da aplicación. Cada un pode rexeitar unha petición que o encamiñamento entregou perfectamente.

A aceptación ten que ser a operación real da aplicación. Un ping correcto non concede acceso á aplicación nin demostra que o nome TLS e as credenciais sexan correctos, e un ping bloqueado non establece que todos os servizos privados estean caídos.

Comprobación 4: fai falta realmente unha conexión separada

Unha VPN aínda pode formar parte do deseño, pero por un motivo declarado: conectar este VPC a unha oficina, admitir portátiles ou cumprir un requisito de superposición. Ese motivo é distinto da comunicación normal dentro do mesmo VPC.

Lembre tamén o que non é un VPC. Non é unha extensión dun segmento Ethernet doméstico. Unha aplicación que depende do descubrimento por difusión ten un requisito aparte que avaliar. Iso é unha lagoa de deseño e non un erro de encamiñamento.

Comprobación 5: a cuestión do cifrado

Un enderezo privado e unha regra de permiso non din nada sobre a protección criptográfica na capa de aplicación. Se os datos necesitan protección de extremo a extremo, esta vén do protocolo e do modelo de identidade que o servizo admite realmente.

Manteña separadas as afirmacións sobre a capa de rede e a capa de aplicación na nota de deseño, porque fusionalas é como unha revisión acaba afirmando unha protección que ninguén implementou.

Que convén rexistrar

Rexistre os dous identificadores de subrede, a táboa de rutas asociada a cada unha, as referencias dos grupos de seguridade e a operación de aplicación que probou. Son catro datos e resolven a maioría das discusións futuras sobre esta ruta.

A localización nunha zona por si soa nunca lle di que engada unha VPN e nunca explica por que fallou unha petición privada.