Por que SSL VPN e VPN de sitio a sitio non son opostos
SSL VPN e VPN de sitio a sitio describen eixes distintos: quen se une á rede e como se constrúe o túnel. Nomear ambos á vez é un erro de categoría.
Pida a dous administradores que describan a mesma VPN e un pode responder «SSL VPN» mentres o outro di «de sitio a sitio», coma se fosen opcións rivais dun menú. Son respostas a preguntas diferentes, e tratalas como alternativas produce comparacións que non se poden resolver. Unha etiqueta di que extremos se unen; a outra di que transporta o tráfico entre eles. Manteña os eixes separados e a maior parte da discusión desaparece.
Dúas etiquetas, dúas preguntas separadas
A topoloxía responde quen se une a que. Un deseño de acceso remoto conecta usuarios ou dispositivos individuais a unha pasarela, normalmente con identidade por usuario e un conxunto de enderezos. Un deseño de sitio a sitio une dúas redes mediante pasarelas, así que a identidade interesante é a pasarela par e non a persoa fronte ao teclado. Son problemas operativos distintos, desde a planificación de enderezos ata quen pode revogar o acceso ás 2 da madrugada.
O mecanismo responde como se constrúe e autentica o túnel. IPsec con IKEv2, un produto baseado en TLS que transporta IP dentro de si, e un portal de aplicacións orientado ao navegador son eleccións de mecanismo, e cada unha ten a súa propia negociación, os seus conxuntos de cifrado e os seus modos de fallo. Ningunha implica unha topoloxía, e unha topoloxía non escolle un mecanismo.
Pon os dous eixes nunha táboa e a confusión faise visible, porque cada cela da grella se pode encher. O que a grella non pode facer é dicirlle que combinación entregou o seu provedor, xa que os nomes de produto colapsan ambos os eixes nunha soa frase de mercadotecnia.
De onde vén o erro de categoría
Os provedores venderon «SSL VPN» durante anos como o oposto de «IPsec VPN», o que facía que unha comparación de mecanismos parecese unha elección de topoloxía. A frase tamén envelleceu mal polos seus propios termos, xa que os deseños actuais usan versións de TLS admitidas e o nome SSL sobrevive sobre todo como categoría de produto.
| Axis | Question it settles | What it cannot tell you |
|---|---|---|
| Topology | Whether users join a gateway or two networks join each other | Which protocol carries the traffic, or how peers prove identity |
| Mechanism | Which protocol suite builds the tunnel and negotiates keys | Whether the endpoints are people, devices or routers |
| Access surface | Whether the client sees a routed network or a set of published applications | Which topology or mechanism is underneath the portal |
| Authentication | What proof each side presents, and to whom | Whether the traffic is later authorized per resource |
Dous mitos relacionados derívanse do mesmo colapso. O primeiro é que IPsec significa de sitio a sitio; IKEv2 deseñouse tamén para relacións de cliente a pasarela, así que un portátil individual pode unirse con IPsec. O segundo é que un produto baseado en TLS significa só acceso remoto; OpenVPN úsase habitualmente para transportar tráfico entre dous sitios, e o seu uso de TLS concéntrase no intercambio de control e autenticación máis que nunha sesión de navegador.
Unha proba útil para calquera descrición: se cambiar unha palabra cambia tanto os extremos como o protocolo, a frase mestura os eixes. «SSL VPN fronte a de sitio a sitio» falla esa proba, porque o primeiro termo nomea unha familia de mecanismos e o segundo unha topoloxía.
Describa un despregamento para que se poida comparar
Escriba catro casas e énchaas: extremos, mecanismo, autenticación e superficie de acceso. Unha ligazón de sucursal podería lerse como un par de pasarelas IKEv2 entre dous prefixos nomeados con autenticación por certificado e sen portal a nivel de usuario. Un servizo de acceso remoto podería lerse como un cliente baseado en TLS que asigna enderezos por usuario, esixe un segundo factor ao iniciar sesión e publica só unha zona DNS interna.
Esas frases son comparables dunha maneira en que os nomes de produto non o son. Dous deseños de acceso remoto pódense medir contra o mesmo fluxo de traballo de usuario e a mesma ruta de revogación, e dous deseños entre sitios contra a mesma lista de prefixos, política de tráfico e requisitos de fallo. As etiquetas organizan a comparación; non a substitúen.
A terminoloxía tamén ten unha áncora publicada. O documento de terminoloxía VPN do IETF separa varios modelos de servizo, incluídos o acceso remoto e o de sitio a sitio, dos mecanismos cos que se constrúen, que é exactamente a distinción que non deixa de perderse.
Lea o protocolo negociado, non o nome do produto
A etiqueta da caixa non establece a que chegou un túnel en funcionamento. Pregunte ao par directamente, no lado TLS, e lea a versión de protocolo e o cifrado que produciu o aperto de mans en lugar da versión do folleto.
openssl s_client -connect vpn.example.net:443 -tls1_3 -briefPara unha pasarela IPsec a observación equivalente vén da saída de estado da propia implementación, que informa das propostas IKE e ESP en uso. En calquera caso, o punto é o mesmo: o eixe do mecanismo debe lerse da sesión viva, porque un cliente e unha pasarela poden negociar á baixa ata algo máis antigo do que esperaba calquera dos dous administradores.
ipsec statusall | grep -E "IKE|ESP"Despois diso, as preguntas que quedan son as que ningunha etiqueta responde. Que versións de protocolo se seguen aceptando, como se valida a identidade da pasarela, que conxunto de algoritmos se permite, quen autoriza a un usuario concreto para un recurso concreto e que revoga o acceso cando se perde un dispositivo. Un diagrama de topoloxía e un nome de mecanismo son o comezo desa lista, non un substituto dela.
Manteña, pois, as dúas etiquetas, pero úseas para o que son: unha forma breve de dicir que extremos se unen e como se constrúe o túnel. No momento en que unha se usa para descartar a outra, a descrición deixou de describir nada.