As regras de AWS Client VPN van no recurso, non na subrede

O persoal necesita chegar a unha aplicación na VPC e non debe chegar ao listener de base de datos da mesma instancia, así que alguén engade unha segunda subrede pública para o endpoint de VPN e dá o requisito por cumprido. A localización da subrede cambia o encamiñamento e a dispoñibilidade. Non concede nin denega un só porto. O permiso que expresa o requisito vive no destino, no grupo de seguridade do recurso, e a fronteira da VPN fornece a asa á que se refire esa regra.

A localización da subrede é encamiñamento, non autorización

Onde se sitúa a asociación de rede do endpoint decide que táboa de rutas transporta o tráfico dos clientes e que zonas de dispoñibilidade sobreviven a un fallo. Non di nada sobre que porto de que instancia pode alcanzar ese tráfico. Dous clientes asociados á mesma subrede seguen chegando coa mesma identidade de orixe, e o recurso non pode distinguilos polo nome da subrede.

Comeza mellor polo requisito: quen chama, que recurso, que porto de servizo e en que dirección. Despois escolle o modelo de regra que poida expresar esas catro cousas no destino. Ese enfoque adoita eliminar por completo a subrede adicional do deseño.

O grupo de asociación de Client VPN é a asa

Para un endpoint de AWS Client VPN asociado a unha subrede, a disposición documentada é concreta. Aplica o grupo de seguridade previsto ás asociacións de rede de destino do endpoint e despois permite o tráfico necesario no grupo de seguridade do recurso usando ese grupo de Client VPN como orixe.

En concreto, o grupo da instancia de aplicación permite o porto da aplicación desde o grupo de asociación, e nada máis. O procedemento de acceso ao recurso de AWS describe esa relación, e convén manter a mesma política de grupo en cada subrede coa que se asocia o endpoint, porque unha asociación obsoleta con outro grupo amplía a fronteira sen facer ruído.

Esa regra non autentica a ninguén. O inicio de sesión é un control aparte, e a ruta ata o recurso é un terceiro. Os tres deben cumprirse antes de que chegue unha petición. O que falle decide que corrección é a correcta, e cambiar a regra é a resposta acertada só para o primeiro.

O que un só grupo de asociación non pode distinguir

Cada cliente detrás do mesmo grupo de asociación chega ao recurso como a mesma orixe de grupo de seguridade. Dous usuarios con roles distintos son indistinguibles nesa capa, por moito que se nomee ou etiquete o grupo. A autorización de grupos externos de Client VPN limita o acceso por prefixo de destino para un grupo de directorio ou SAML, o que é máis groso que un rol de recurso e debe tratarse como unha fronteira de rede, non como un sistema de identidade.

As distincións máis finas pertencen á aplicación. Un listener de base de datos que debe permanecer pechado para a maioría do persoal está mellor protexido se non é accesible de ningún xeito no prefixo permitido que se se espera que a pertenza ao grupo siga ordenada.

Renomear o grupo non crea unha identidade, e duplicalo por equipo só multiplica as asociacións que hai que auditar.

Non copies esa regra en todos os deseños de VPN

Unha pasarela EC2 VPN autoxestionada, un aparello de inspección encamiñado e un Client VPN xestionado son tres camiños de paquetes distintos. Establece que enderezo de orixe chega realmente ao recurso, se hai tradución polo medio e que mecanismos de referencia admite o servizo nese camiño.

Reenviar o tráfico por un dispositivo intermedio non conserva unha referencia de grupo de seguridade de orixe como o fai o tráfico directo entre instancias. AWS documenta que eses deseños poden necesitar os enderezos privados de orixe ou os CIDR axeitados en lugar dunha referencia de grupo. O procedemento de Client VPN xestionado non demostra que o grupo adxunto de cada pasarela funcione como un token de identidade universal para os paquetes reenviados.

Un só salto NAT no camiño abonda para romper a suposición, e o fallo parece unha regra que está presente pero nunca coincide.

Revisa a fronteira efectiva

Le cada grupo de seguridade adxunto ao recurso, porque as regras de permiso se combinan e unha regra estreita non anula outra máis ampla noutro grupo. Despois comproba a ACL de rede, a devasa do host e a autorización propia da aplicación, que son capas separadas con erros separados.

Termina cunha petición permitida e outra deliberadamente excluída contra o mesmo recurso. A parella demostra a fronteira, mentres que unha única conexión correcta só demostra que algo está aberto. Confirma a ruta, a orixe efectiva e o porto de servizo previsto, non a subrede que contén o endpoint.

Orde de traballo: escribe o requisito de catro partes, adxunta o grupo ás asociacións, limita a regra do recurso ao porto, verifica un permiso e unha denegación, e só despois considera dividir subredes por motivos de encamiñamento.