AWS Client VPN ou unha VPN en EC2: un manual de operación

Ambas as opcións dan ao teu equipo unha VPN de acceso remoto, así que a pregunta interesante non é cal existe, senón cal podes operar. A diferenza é quen é o dono do punto de conexión ás 3 da madrugada e a que controis chegas cando algo se rompe. Segue os cinco pasos de abaixo en orde, porque cada un pode rematar a comparación antes de tempo. Saltarse o paso de inventario é xusto como os equipos acaban migrando dúas veces.

Paso 1: escribe o requisito antes da factura

Necesitas cinco feitos nunha páxina: quen se autentica e contra que, que plataformas de cliente deben funcionar, que destinos privados son accesibles, que dispoñibilidade prometiches e como é o tráfico en realidade. Sen iso, calquera comparación posterior convértese nunha discusión sobre unha lista de funcións.

Sé concreto cos destinos. «Acceso á VPC» adoita significar tres cousas distintas: o CIDR da VPC, unha rede emparellada e un rango local detrás dun Transit Gateway. Un punto de conexión xestionado alcanza os tres, pero cada un necesita unha ruta e unha regra de autorización, e cada un é unha liña aparte no teu requisito.

Paso 2: enumera o que xa funciona

Antes de deseñar nada, enumera os puntos de conexión existentes e calquera servidor aloxado en EC2 xunto cos seus grupos de seguridade. Estas chamadas son de só lectura e seguras desde unha conta con permisos describe.

aws ec2 describe-client-vpn-endpoints
aws ec2 describe-client-vpn-authorization-rules --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-routes --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-connections --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-instances --filters Name=tag:role,Values=vpn

Le a saída como un mapa do que os clientes xa alcanzan. Unha regra de autorización que falta explica un fallo que parece un problema de encamiñamento, e un punto de conexión asociado a unha soa subrede explica por que un fallo de zona botou abaixo todo o servizo.

Anota tamén os grupos de seguridade asociados a calquera instancia autoaloxada. Esas regras forman parte do modelo de acceso e son o primeiro que se rompe en silencio cando alguén reconstrúe unha instancia a partir dun modelo.

Paso 3: reparte as responsabilidades

O servizo xestionado é dono da frota de puntos de conexión, do seu parcheo e da súa dispoñibilidade dentro da rexión. Ti es dono da alta de identidades, as regras de autorización, as rutas de rede detrás do punto de conexión, a configuración de rexistros e a decisión de cantas subredes asociar.

A autoaloxamento invérteo. Ti es dono do sistema operativo convidado, do daemon VPN e a súa configuración, dos certificados e claves, das copias de seguridade, da monitorización e da recuperación. O modelo de seguridade de EC2 pon a seguridade do convidado e da aplicación no cliente, e un servidor VPN é un convidado coma calquera outro.

Escribe o reparto como unha táboa con nomes na columna da dereita. Se ningún nome aparece xunto á renovación de certificados, ese é o achado, e pesa máis ca diferenza por hora.

Paso 4: compara cunha carga de traballo que poidas describir

O custo segue a forma, non o tamaño. Para a opción xestionada, conta as horas de asociación de puntos de conexión, as horas de conexión de clientes, a transferencia e os servizos de identidade e rexistros que actives. Para a autoaloxamento, conta a computación, o almacenamento, a rede, as licenzas e o tempo de enxeñaría que mantén o servidor parcheado. Pon ambos os conxuntos de cifras nunha folla co mesmo horizonte temporal. Unha comparación a tres anos que ignore as horas de parcheo sempre favorecerá o servidor que xa tes.

As comparacións de rendemento necesitan a mesma disciplina. Unha sesión interactiva de escritorio, unha transferencia grande e cincuenta solicitudes pequenas simultáneas estresan partes distintas do camiño: a CPU para o cifrado, a capacidade de rede da instancia, a pila propia do cliente e o destino. Proba con clientes representativos e a mesma tarefa nos dous deseños.

Unha instancia máis grande non é proba de que unha transferencia será máis rápida, e unha sesión exitosa non é un plan de capacidade. Trata calquera folclore herdado sobre familias de instancias como unha hipótese que probar, non como unha regra de compra.

Paso 5: migra cunha reversión que xa executases

Executa ambos os puntos de conexión en paralelo durante un período definido, distribúe primeiro o perfil de cliente novo a un grupo pequeno e non toques as regras de autorización do punto de conexión antigo ata que o grupo teña usado o novo en traballo real. A reversión é un cambio de perfil, non unha reconstrución, así que decide agora onde vive o perfil antigo.

Verifica nesta orde: a autenticación ten éxito, o cliente recibe as rutas esperadas, un destino autorizado responde e un destino non autorizado falla, e os rexistros mostran ambos os eventos. Se falla calquera paso, detente e arranxa ese paso en lugar de pasar ao seguinte grupo de clientes. Anota o resultado de cada comprobación, porque unha migración recordada só como «funcionou» non se pode depurar un mes despois.

Despois da migración, programa as comprobacións aburridas: a caducidade dos certificados, o número de asociacións, as regras de autorización que xa non coinciden con ningún grupo e o número de conexións fronte á túa expectativa. A Guía de administración de Client VPN é a referencia para as pezas de punto de conexión, autenticación e encamiñamento que configuraches.