¿SSL VPN o envoltorio TLS? Compare el límite que falló

Dos diseños pueden ejecutar TLS en el puerto 443 y significar cosas completamente distintas. Un envoltorio protege una conexión configurada entre un puerto local y un backend remoto. Un diseño de acceso a la red transporta tráfico seleccionado y cambia a qué puede llegar el cliente. Haga las cuatro comprobaciones siguientes en orden y sabrá cuál de los dos está viendo, lo que suele bastar para saber qué capa falló.

Empiece por la conexión que realmente configuró

Anote el extremo frontal y el trasero antes de comparar productos. Un envoltorio escucha en una dirección local y reenvía a una remota, o inicia un programa en el lado remoto, y ese par es todo su contrato. Las demás aplicaciones del cliente no saben nada de él a menos que las dirija hacia él. Eso no es una carencia de la herramienta, es para lo que sirve la herramienta.

El contrato de un diseño de red es distinto y se expresa en rutas y políticas, no en un par de puertos.

Fíjese en cuál de esas dos descripciones coincide con su diagrama. Si la respuesta es una asignación de puerto con un certificado en medio, tiene un envoltorio aunque el nombre del producto diga VPN. Si la respuesta es una interfaz de túnel y cambios de ruta, tiene un diseño de red aunque se ejecute en el 443.

Compruebe a qué se conecta el envoltorio

Lea los ajustes de escucha y conexión y sígalos hasta el backend real. Un envoltorio que reenvía a un puerto de base de datos no abre una aplicación web, y un envoltorio que ejecuta un programa inicia ese programa en lugar de publicar todo lo demás que ejecuta el host. El backend es lo único que el envoltorio conoce.

Después decida si el flujo reenviado es texto plano cuando termina TLS. Una conexión envuelta protege el segmento entre los dos envoltorios, y lo que ocurre tras el envoltorio lejano es una cuestión aparte. Por eso envolver algo que ya lleva su propia protección a veces es sensato y a veces son solo piezas móviles de más. Inspeccione el siguiente salto en lugar de suponer cualquiera de las dos respuestas.

openssl s_client -connect wrapper.lab.example:443 -servername wrapper.lab.example -verify_return_error
sudo ss -ltnp | grep 443

El primer comando muestra el certificado que realmente se ofrece a un cliente, y el segundo muestra qué escucha en el host. Compare ese nombre de certificado con el que esperaba antes de leer nada más.

Compruebe qué tráfico transporta el diseño

Los diseños de acceso a la red transportan tráfico seleccionado y se integran con el enrutamiento y la política de acceso del cliente. La admisión no es autorización, así que una conexión autenticada aún necesita una decisión sobre a qué recursos puede llegar. Un portal sin cliente es un tercer modelo que hace de proxy de las operaciones admitidas sin aparecer nunca como una interfaz tun.

La etiqueta del producto no le dice cuál de esos modelos compró, y el número de puerto dice aún menos.

El apilamiento es posible y no debe confundir la comparación. Un protocolo de túnel puede ir él mismo envuelto en TLS en una disposición TCP admitida, lo que añade una capa alrededor del túnel sin convertir el envoltorio en el túnel. Es una decisión de diseño con su propio comportamiento de rendimiento y de fallo, y merece una línea en el diagrama. Anótela y después compare los modelos subyacentes, no el envoltorio exterior.

Compruebe el límite que falló, no la etiqueta

Anote los hechos de un intento fallido: dirección frontal, oyente, la identidad que el cliente verificó, el destino del backend y la operación solicitada. Un apretón de manos exitoso demuestra que el TLS exterior se completó y no dice nada del backend. Un rechazo del backend es un evento distinto de un fallo de identidad en el frontal, y ninguno mejora si se quita -verify_return_error del cliente. Compare lo comparable, porque un éxito por otro nombre de host o puerto no demuestra que las condiciones fueran las mismas.

El puerto 443 es una convención que deja pasar TLS por los dispositivos intermedios. No hace que el tráfico arbitrario parezca una petición web para un dispositivo de políticas.

Termine con una frase que nombre el par de extremos, qué se transporta, qué aplicaciones lo usan y qué permiso impone el destino. Un diseño que no puede rellenar esos cuatro huecos no está terminado, diga lo que diga su etiqueta. Esa frase es también la forma más rápida de explicar el diseño a quien sea el propietario del cortafuegos.