TLS nativo, reenvío SSH o VPN para un servicio en la nube

La pregunta rara vez es si cifrar algo entre dos máquinas en la nube; es qué interfaz se cifra y quién comprueba la identidad de quién. Empiezo estas conversaciones por el servicio y no por el diagrama de red, porque el servicio ya sabe qué necesita. Tres límites cubren la mayoría de los casos: el TLS propio de la aplicación, un único puerto TCP reenviado por SSH y una superposición enrutada que da una dirección a cada participante. No se ordenan por fuerza, sino por cuánto del problema cubren.

Empiece por el servicio, no por la red

Avance desde el proceso hacia fuera. ¿Qué protocolo habla, qué nombre verificará el cliente y quién puede abrir una conexión? Esas tres respuestas eliminan opciones más rápido que cualquier tabla comparativa, y la propia configuración del servicio suele responderlas en un par de minutos.

Tome una API interna pequeña que ya sirve HTTPS en el puerto 8443 con un certificado para api.internal.example. ss -ltnp en el host muestra a qué se enlaza, y openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example muestra si el certificado valida para el nombre que el cliente usará realmente. Si ambos están sanos, el servicio puede proteger su propio flujo y solo queda la accesibilidad. Eso es un problema mucho menor que construir una red.

Paso 1: ¿se protege el servicio a sí mismo?

Esta es la opción que se toma cuando encaja, y encaja más a menudo de lo que los equipos suponen. El cifrado del servicio cubre todo el camino entre cliente y servidor, incluidos todos los saltos intermedios, algo que ningún túnel alrededor del medio mejora. Configure el nombre esperado y la confianza de forma explícita en lugar de confiar en lo que contenga por casualidad el almacén predeterminado del cliente.

El cifrado y la accesibilidad siguen siendo controles separados, y fusionarlos es donde esta opción falla. Un servicio TLS en un oyente público sin restricciones sigue aceptando intentos de conexión de cualquiera, así que el oyente y las reglas de red deben delimitarse con independencia de que la carga útil esté protegida. Luego revise las dependencias, porque una API sobre TLS no dice nada sobre el punto de descubrimiento, el puerto de administración o el canal de transferencia masiva que tiene al lado. Cada uno necesita su propia respuesta, y un hermano desprotegido basta para convertir todo el límite en una ficción.

Paso 2: ¿es un solo puerto TCP todo el requisito?

Cuando el requisito es realmente un solo puerto TCP, un reenvío es lo más pequeño que funciona. Un reenvío local SSH transporta ese puerto a través de una conexión autenticada que ya existe.

La forma es ssh -N -L 8443:127.0.0.1:8443 [email protected], y el detalle que importa es la dirección de destino: 127.0.0.1 se resuelve en el lado remoto, así que la conexión al servicio se abre desde el bastión y no desde su portátil. Enlace el oyente local de forma estrecha como -L 127.0.0.1:8443:... para no publicar el servicio en su propia red local por accidente. En el lado del servidor, limite lo que la cuenta puede reenviar en lugar de confiar en que el cliente se comporte. PermitOpen, AllowTcpForwarding local y un GatewayPorts no predeterminado son los tres ajustes que convierten un relé genérico en un canal concreto.

El contrato es estrecho en ambas direcciones. SSH protege su propio canal, y un salto adicional del bastión a otra aplicación necesita su propia protección. Un servicio que escucha solo en el loopback del bastión tiene una exposición muy distinta de uno al que se llega por otra red, y el reenvío no lo cambia. Mantenga la autenticación y las comprobaciones TLS de la aplicación en su sitio en lugar de tratar el túnel como su sustituto.

Esto funciona bien para una conexión con un propietario. A escala se convierte en un sistema: conflictos de puertos locales, supervisión, rotación de claves y la pregunta de quién reinicia el reenvío tras un reinicio.

Paso 3: ¿es el enrutamiento el requisito real?

Esa lista es el coste honesto de la opción más pequeña, y por eso los equipos acaban sustituyendo un puñado de comandos en segundo plano olvidados por algo gestionado. La sustitución no es automáticamente una VPN. Si el requisito sigue siendo un solo puerto TCP, un reenvío supervisado con un propietario documentado es más barato de operar que una superposición y falla de formas que usted puede ver. Mida la propiedad operativa antes de medir la elegancia.

El enrutamiento se convierte en la respuesta correcta cuando el enrutamiento es el requisito. Varias aplicaciones que necesitan conectividad IP corriente, protocolos que un reenvío TCP no puede transportar o servicios que se mueven entre hosts apuntan todos en la misma dirección.

Una superposición da a los participantes una dirección y una ruta, y entonces empieza el trabajo real: rangos que no se solapan, propiedad de rutas, DNS, inscripción, revocación y qué ocurre cuando un par desaparece. Nada de eso llega con la dirección. Un par admitido en la superposición tampoco está autorizado automáticamente para cada operación en el destino, así que la autenticación a nivel de servicio se mantiene.

Qué posee después

Dos cosas pertenecen al registro que deja. La primera es la identidad que se espera que el cliente verifique, porque cada uno de estos límites se degrada en silencio en cuanto se relaja una comprobación de nombre para hacer funcionar algo. La segunda es el paso de retirada: qué clave, qué regla o qué ruta desaparece cuando termina el acceso, y quién lo ejecuta.

El recorrido termina donde empezó, en el servicio. Elija el límite que cubre el tráfico real y verifica los pares que pretendía verificar, y luego anote cómo se actualiza, se supervisa y se retira el acceso. La referencia de OpenSSH es el lugar para confirmar las opciones de reenvío antes de prometer un contrato estrecho. Si no puede describir el paso de retirada en una frase, el límite es mayor que el problema.