TLS nativo, reenvío SSH ou VPN para un servizo na nube

A pregunta raramente é se cifrar algo entre dúas máquinas na nube; é que interface cifra e quen comproba a identidade de quen. Comezo estas conversas polo servizo e non polo diagrama de rede, porque o servizo xa sabe o que necesita. Tres límites cobren a maioría dos casos: o TLS propio da aplicación, un único porto TCP reenviado por SSH e unha superposición enrutada que dá un enderezo a cada participante. Non se ordenan por forza, senón por canto do problema cobren.

Comece polo servizo, non pola rede

Avance desde o proceso cara a fóra. Que protocolo fala, que nome verificará o cliente e quen pode abrir unha conexión? Esas tres respostas eliminan opcións máis rápido que calquera táboa comparativa, e a propia configuración do servizo adoita respondelas nun par de minutos.

Colla unha API interna pequena que xa serve HTTPS no porto 8443 cun certificado para api.internal.example. ss -ltnp no host mostra a que se liga, e openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example mostra se o certificado valida para o nome que o cliente usará realmente. Se ambos están sans, o servizo pode protexer o seu propio fluxo e só queda a accesibilidade. Iso é un problema moito menor que construír unha rede.

Paso 1: o servizo protéxese a si mesmo?

Esta é a opción que se toma cando encaixa, e encaixa máis a miúdo do que os equipos supoñen. O cifrado do servizo cobre todo o camiño entre cliente e servidor, incluídos todos os saltos intermedios, algo que ningún túnel arredor do medio mellora. Configure o nome esperado e a confianza de forma explícita en lugar de confiar no que conteña por casualidade o almacén predeterminado do cliente.

O cifrado e a accesibilidade seguen sendo controis separados, e fusionalos é onde esta opción falla. Un servizo TLS nun oínte público sen restricións segue aceptando intentos de conexión de calquera, así que o oínte e as regras de rede deben delimitarse con independencia de que a carga útil estea protexida. Logo revise as dependencias, porque unha API sobre TLS non di nada sobre o punto de descuberta, o porto de administración ou a canle de transferencia masiva que ten ao lado. Cada un necesita a súa propia resposta, e un irmán desprotexido abonda para converter todo o límite nunha ficción.

Paso 2: é un só porto TCP todo o requisito?

Cando o requisito é realmente un só porto TCP, un reenvío é o máis pequeno que funciona. Un reenvío local SSH transporta ese porto a través dunha conexión autenticada que xa existe.

A forma é ssh -N -L 8443:127.0.0.1:8443 [email protected], e o detalle que importa é o enderezo de destino: 127.0.0.1 resólvese no lado remoto, así que a conexión ao servizo ábrese desde o bastión e non desde o seu portátil. Ligazón o oínte local de forma estreita como -L 127.0.0.1:8443:... para non publicar o servizo na súa propia rede local por accidente. No lado do servidor, limite o que a conta pode reenviar en lugar de confiar en que o cliente se comporte. PermitOpen, AllowTcpForwarding local e un GatewayPorts no predeterminado son os tres axustes que converten un relé xenérico nunha canle concreta.

O contrato é estreito en ambas as direccións. SSH protexe a súa propia canle, e un salto adicional do bastión a outra aplicación necesita a súa propia protección. Un servizo que só escoita no loopback do bastión ten unha exposición moi distinta dun ao que se chega por outra rede, e o reenvío non o cambia. Manteña a autenticación e as comprobacións TLS da aplicación no seu sitio en lugar de tratar o túnel como o seu substituto.

Isto funciona ben para unha conexión cun propietario. A escala convértese nun sistema: conflitos de portos locais, supervisión, rotación de claves e a pregunta de quen reinicia o reenvío tras un reinicio.

Paso 3: é o enrutamento o requisito real?

Esa lista é o custo honesto da opción máis pequena, e por iso os equipos acaban substituíndo unha manchea de comandos en segundo plano esquecidos por algo xestionado. A substitución non é automaticamente unha VPN. Se o requisito segue sendo un só porto TCP, un reenvío supervisado cun propietario documentado é máis barato de operar que unha superposición e falla de formas que vostede pode ver. Mida a propiedade operativa antes de medir a elegancia.

O enrutamento convértese na resposta correcta cando o enrutamento é o requisito. Varias aplicacións que necesitan conectividade IP corrente, protocolos que un reenvío TCP non pode transportar ou servizos que se moven entre hosts apuntan todos na mesma dirección.

Unha superposición dá aos participantes un enderezo e unha ruta, e entón comeza o traballo real: rangos que non se solapan, propiedade de rutas, DNS, inscrición, revogación e que ocorre cando un par desaparece. Nada diso chega co enderezo. Un par admitido na superposición tampouco está autorizado automaticamente para cada operación no destino, así que a autenticación a nivel de servizo mantense.

Que posúe despois

Dúas cousas pertencen ao rexistro que deixa. A primeira é a identidade que se espera que o cliente verifique, porque cada un destes límites degrádase en silencio en canto se relaxa unha comprobación de nome para facer funcionar algo. A segunda é o paso de retirada: que clave, que regra ou que ruta desaparece cando remata o acceso, e quen o executa.

O percorrido remata onde comezou, no servizo. Escolla o límite que cobre o tráfico real e verifica os pares que pretendía verificar, e logo anote como se actualiza, se supervisa e se retira o acceso. A referencia de OpenSSH é o lugar para confirmar as opcións de reenvío antes de prometer un contrato estreito. Se non pode describir o paso de retirada nunha frase, o límite é maior que o problema.