Acceso intermitente con AWS Client VPN: audite cada subrede asociada

Un usuario conéctase, abre a aplicación interna e obtén resposta; un compañeiro no mesmo punto de conexión recibe un tempo de espera desde un portátil idéntico na mesma Wi-Fi. Ese patrón é a sinatura dun punto de conexión de client VPN con máis dunha subrede asociada, onde os camiños non son equivalentes. Percorro isto desde a consola cara a fóra, porque dúas pestanas deciden se paga a pena o resto da investigación. Nada na configuración do cliente o explica.

Comece polo punto de conexión e liste as asociacións

Na consola de VPC, abra Client VPN endpoints, escolla o punto de conexión e lea a pestana Associations. Cada asociación é unha subrede nunha zona de dispoñibilidade, e o cliente aterra na que escolla o servizo cando se constrúe a conexión. Anote os identificadores de subrede e a táboa de rutas que realmente usa cada unha, porque esas dúas listas son a comparación que está a piques de facer.

Se o punto de conexión mostra unha soa asociación, esta teoría é falsa e o cliente é o mellor sospeitoso.

Compare a táboa de rutas do punto de conexión con cada asociación

Abra a pestana Route table no mesmo punto de conexión. Cada CIDR de destino alí ten un obxectivo, e nun client VPN o obxectivo é unha asociación e non unha pasarela. AWS esixe unha entrada de destino para cada subrede asociada, así que unha ruta que só apunta a unha delas fai que o acceso dependa de onde aterrou a sesión. Revise o destino que realmente lle importa e despois a súa regra de autorización, porque a ruta achega o camiño e a regra decide quen pode usalo.

Cando tabula ambas as capas, o fallo é difícil de pasar por alto.

A segunda fila é todo o fallo na maioría dos tíquets. A ruta do punto de conexión está aí, así que ninguén mira máis alá, e o paquete morre un salto despois dentro da VPC.

Siga cada subrede ata a súa táboa de rutas efectiva

Unha subrede sen asociación explícita a unha táboa de rutas herda a táboa principal da VPC. Lea a táboa que realmente está en vigor, non a que parece ter o nome correcto, e compare destino e obxectivo en lugar da etiqueta da fila.

A guía de AWS sobre acceso intermitente expón isto como cobertura de rutas entre asociacións, que é o modelo correcto. O punto de conexión leva o paquete a unha subrede, e a táboa desa subrede aínda ten que saber onde vive a rede da aplicación.

Corrixa a fila que falta na táboa que a posúe. Copiar toda unha táboa de rutas dunha subrede que funciona tamén copia decisións de internet, aparellos e illamento que nunca estiveron pensadas para esta, e ese intercambio adoita ser peor que a caída coa que comezou.

Revise as regras de autorización e despois o camiño de volta

As regras de autorización son por destino e por grupo, e avalíanse por separado das rutas. Un destino con rutas por todas partes pero sen regra para o grupo do usuario compórtase como un burato negro cunha táboa de rutas que parece sa.

O camiño de volta merece a mesma atención. Unha conexión de peering necesita unha ruta na VPC da aplicación que apunte de volta ao CIDR do cliente, regras de grupo de seguridade que permitan o tráfico nos dous extremos e ACL de rede que non o descarten. A alcanzabilidade nun só sentido, onde ping funciona e o aperto de mans TCP non, adoita apuntar a unha ACL ou a un grupo de seguridade e non á VPN.

Os grupos de seguridade do propio punto de conexión asentan sobre as interfaces de rede elásticas da asociación, así que unha regra que permita o porto da aplicación desde o CIDR do cliente debe anexarse á asociación, non só á instancia.

Verifique cunha reconexión, non cunha petición afortunada

Con túnel dividido, as rutas do punto de conexión envíanse cando se establece a conexión, así que un conxunto de rutas cambiado nunca chega a un cliente que permanece conectado. Desconecte e volva conectar co cliente compatible, e despois confirme que as rutas novas están na máquina.

Por último, correlacione o rexistro de conexións co enderezo que recibiu o cliente e repita a proba as veces suficientes para atopar máis dunha asociación. Unha soa petición correcta tras unha corrección demostra que un camiño funciona, e o tíquet era sobre o outro.