Un portátil conectado mediante AWS Client VPN chega a unha aplicación de EC2 sen problemas. Despois probas o contrario, desde EC2 cara ao enderezo que se asignou ao cliente, e a conexión queda colgada ou rexéitase. Esa asimetría raramente se debe a unha regra de grupo de seguridade que falte. Nun punto de conexión de Client VPN asociado a subredes de VPC, AWS traduce as fontes IPv4 do cliente á interface de rede do punto de conexión, así que non existe un enderezo de VPC de entrada que represente o teu portátil.

Comeza por aquilo que mostra a captura

Fai unha captura no equipo EC2 mentres o cliente se conecta e le o enderezo de orixe que ve realmente a aplicación. Se é a interface do punto de conexión do lado da VPC e non un enderezo do grupo de clientes, a tradución queda confirmada antes de cambiar unha soa regra.

O grupo de clientes é un rango de asignación, non unha subrede cunha ruta de retorno. Ese é o punto onde fallan a maioría destas investigacións.

A tradución que explica a asimetría

Tres fluxos confúndense entre si, e só un deles é o que a xente proba.

FlowStarted byWhat the VPC seesOutcome
Client to EC2 serviceThe clientA translated source at the endpoint interfaceWorks, with a stateful reply
EC2 host to client pool addressThe EC2 hostA destination with no route and no translation stateNo usable path
Client to clientA client, when the feature is configuredTraffic mediated by the endpointWorks only with that feature and its authorisation

A descrición dos compoñentes de Client VPN explica que as fontes IPv4 do cliente se traducen á interface do punto de conexión, o que abonda para ver por que a fila central non ten con que coincidir.

Unha conexión nova necesita unha ruta, un paso de resolución de enderezos e unha decisión de autorización. O estado de tradución da sesión doutra persoa non achega ningún dos tres.

Por que unha resposta non é unha conexión nova

Unha resposta TCP compárase cunha entrada existente, e por iso o camiño de volta funciona sen ningunha regra de entrada. Un SYN novo do equipo EC2 non ten ningunha entrada coa que coincidir, así que se converte nun intento de saída normal cara a un destino ao que a VPC non sabe chegar.

Tamén por iso é enganoso describilo como tráfico que só vai nun sentido. O tráfico de volta flúe de forma continua nestas sesións. A parte que non ten camiño é o inicio.

Que segue a romper unha sesión que debería funcionar

Os grupos de seguridade, as listas de control de acceso de rede e a devasa do propio portátil importan para as conexións que deberían funcionar. Un ping fallido é o que menos che di, porque a política de ICMP adoita ser independente da política de TCP que che interesa.

Escribe esas regras respecto da orixe traducida, non do enderezo do cliente. As regras ligadas ao enderezo que nunca aparece na rede son o fallo autoinxerido máis común deste deseño.

Cando a VPC realmente ten que iniciar a conversa

Se un servizo ten que avisar un posto de traballo, inverte a dirección e deixa que o cliente manteña unha canle de saída persistente á que responda o servizo. Se toda unha rede remota debe ser accesible desde a VPC, escolle unha arquitectura que publique os seus prefixos e a súa política de acceso en lugar de supoñer que Client VPN xa o fai. O acceso cliente a cliente é un terceiro caso, máis estreito, cos seus propios obxectos de ruta e autorización. Nada disto é unha caixa de verificación no punto de conexión existente.

Mantén honesto tamén o alcance da explicación de IPv4. A documentación actual de AWS separa IPv6, onde esa tradución non se aplica, e outros modelos de conexión que encamiñan de forma distinta.

Proba en tres pasos etiquetados: o cliente abre unha sesión permitida, o servizo da VPC responde a esa sesión e un equipo da VPC abre unha sesión nova cara ao cliente. Que os dous primeiros funcionen e o terceiro falle é a forma agardada deste deseño, non un defecto que haxa que perseguir con regras de devasa.

Artigos relacionados