Por qué SSL VPN y VPN de sitio a sitio no son opuestos

Pida a dos administradores que describan la misma VPN y uno puede responder «SSL VPN» mientras el otro dice «de sitio a sitio», como si fueran opciones rivales de un menú. Son respuestas a preguntas diferentes, y tratarlas como alternativas produce comparaciones que no se pueden resolver. Una etiqueta dice qué extremos se unen; la otra dice qué transporta el tráfico entre ellos. Mantenga los ejes separados y la mayor parte de la discusión desaparece.

Dos etiquetas, dos preguntas separadas

La topología responde quién se une a qué. Un diseño de acceso remoto conecta usuarios o dispositivos individuales a una puerta de enlace, normalmente con identidad por usuario y un grupo de direcciones. Un diseño de sitio a sitio une dos redes mediante puertas de enlace, así que la identidad interesante es la puerta de enlace par y no la persona frente al teclado. Son problemas operativos distintos, desde la planificación de direcciones hasta quién puede revocar el acceso a las 2 de la madrugada.

El mecanismo responde cómo se construye y autentica el túnel. IPsec con IKEv2, un producto basado en TLS que transporta IP dentro de sí, y un portal de aplicaciones orientado al navegador son elecciones de mecanismo, y cada una tiene su propia negociación, sus conjuntos de cifrado y sus modos de fallo. Ninguna implica una topología, y una topología no elige un mecanismo.

Ponga los dos ejes en una tabla y la confusión se hace visible, porque cada celda de la cuadrícula se puede rellenar. Lo que la cuadrícula no puede hacer es decirle qué combinación entregó su proveedor, ya que los nombres de producto colapsan ambos ejes en una sola frase de marketing.

De dónde viene el error de categoría

Los proveedores vendieron «SSL VPN» durante años como lo opuesto de «IPsec VPN», lo que hacía que una comparación de mecanismos pareciera una elección de topología. La frase también ha envejecido mal por sus propios términos, ya que los diseños actuales usan versiones de TLS compatibles y el nombre SSL sobrevive sobre todo como categoría de producto.

Dos mitos relacionados se derivan del mismo colapso. El primero es que IPsec significa de sitio a sitio; IKEv2 se diseñó también para relaciones de cliente a puerta de enlace, así que un portátil individual puede unirse con IPsec. El segundo es que un producto basado en TLS significa solo acceso remoto; OpenVPN se usa habitualmente para transportar tráfico entre dos sitios, y su uso de TLS se concentra en el intercambio de control y autenticación más que en una sesión de navegador.

Una prueba útil para cualquier descripción: si cambiar una palabra cambia tanto los extremos como el protocolo, la frase mezcla los ejes. «SSL VPN frente a de sitio a sitio» falla esa prueba, porque el primer término nombra una familia de mecanismos y el segundo una topología.

Describa un despliegue para que se pueda comparar

Escriba cuatro casillas y rellénelas: extremos, mecanismo, autenticación y superficie de acceso. Un enlace de sucursal podría leerse como un par de puertas de enlace IKEv2 entre dos prefijos nombrados con autenticación por certificado y sin portal a nivel de usuario. Un servicio de acceso remoto podría leerse como un cliente basado en TLS que asigna direcciones por usuario, exige un segundo factor al iniciar sesión y publica solo una zona DNS interna.

Esas frases son comparables de una manera en que los nombres de producto no lo son. Dos diseños de acceso remoto se pueden medir contra el mismo flujo de trabajo de usuario y la misma ruta de revocación, y dos diseños entre sitios contra la misma lista de prefijos, política de tráfico y requisitos de fallo. Las etiquetas organizan la comparación; no la sustituyen.

La terminología también tiene un anclaje publicado. El documento de terminología VPN del IETF separa varios modelos de servicio, incluidos el acceso remoto y el de sitio a sitio, de los mecanismos con los que se construyen, que es exactamente la distinción que no deja de perderse.

Lea el protocolo negociado, no el nombre del producto

La etiqueta de la caja no establece a qué llegó un túnel en funcionamiento. Pregunte al par directamente, en el lado TLS, y lea la versión de protocolo y el cifrado que produjo el apretón de manos en lugar de la versión del folleto.

openssl s_client -connect vpn.example.net:443 -tls1_3 -brief

Para una puerta de enlace IPsec la observación equivalente viene de la salida de estado de la propia implementación, que informa de las propuestas IKE y ESP en uso. En cualquier caso, el punto es el mismo: el eje del mecanismo debe leerse de la sesión viva, porque un cliente y una puerta de enlace pueden negociar a la baja hasta algo más antiguo de lo que esperaba cualquiera de los dos administradores.

ipsec statusall | grep -E "IKE|ESP"

Después de eso, las preguntas que quedan son las que ninguna etiqueta responde. Qué versiones de protocolo se siguen aceptando, cómo se valida la identidad de la puerta de enlace, qué conjunto de algoritmos se permite, quién autoriza a un usuario concreto para un recurso concreto y qué revoca el acceso cuando se pierde un dispositivo. Un diagrama de topología y un nombre de mecanismo son el comienzo de esa lista, no un sustituto de ella.

Conserve, pues, las dos etiquetas, pero úselas para lo que son: una forma breve de decir qué extremos se unen y cómo se construye el túnel. En el momento en que una se usa para descartar la otra, la descripción ha dejado de describir nada.