OpenVPN ou IKEv2: catro comprobacións antes de escoller un protocolo
O soporte do cliente, a mobilidade, a autenticación e o acceso que precisa deciden entre OpenVPN e IKEv2. Os dous perfís non son intercambiables.
A elección entre OpenVPN e IKEv2 adoita discutirse como unha cuestión de protocolo, e ese enfoque desaproveita a decisión. O que a decide é se o seu servidor e os seus dispositivos admiten o mesmo perfil completo, e se ese perfil sobrevive á forma en que se move entre redes. As dúas pilas non se traducen unha na outra: un ficheiro OVPN non é un perfil IKEv2 con outra sintaxe. Catro comprobacións, feitas por orde, responden a pregunta máis rápido que calquera táboa de funcións.
Un cliente que falta remata a discusión
Windows e macOS inclúen un cliente IKEv2, así que un perfil IKEv2 non custa nada extra despregalo alí e herda as opcións de aprovisionamento que o sistema operativo xa expón. OpenVPN nas mesmas máquinas significa un cliente de terceiros que instalar, actualizar e manter, e ese cliente ten que aceptar cada opción que use o perfil. Conta as plataformas que debe cubrir antes de comparar calquera outra cousa, porque unha plataforma sen cliente funcional non é ningún punto de comparación.
En Windows, un comando enumera os perfís que xa existen e mostra de que tipo é cada un. O nome que imprime é o nome que usan as comprobacións posteriores.
Get-VpnConnection -AllUserConnection
Get-VpnConnection -Name <profile-name> | Select-Object Name, ServerAddress, TunnelType
A indicación de instalar un cliente é a resposta real para a columna de OpenVPN nesas plataformas, e é unha tarefa de despregamento e non unha limitación do protocolo. Ningunha das dúas disposicións elimina as comprobacións de confianza, a verificación de identidade nin o mantemento. Pregunte como se distribúen os perfís, como se renovan as credenciais e como se retira un dispositivo perdido antes de comprometerse. Unha instalación sinxela aínda pode agochar un proceso de recuperación que ninguén quere executar na fin de semana.
A mobilidade é un axuste conxunto, non unha promesa do protocolo
IKEv2 pode usar MOBIKE cando ambos os extremos o admiten e o activan, o que permite a un cliente manter o seu túnel mentres cambia o seu enderezo. RFC 4555 define a extensión, e a formulación condicional importa: un servidor que ignora a capacidade volve negociar no seu lugar. O resultado pode parecer idéntico nunha transferencia de ficheiros e moi distinto nunha chamada en directo.
Probe a transición que de verdade lle importa, con algo en marcha que poida observar. Manteña ping -t <internal-host> funcionando en Windows, ou o simple ping noutros sistemas, despois cambie de Wi-Fi a móbil e observe se hai ocos. Un fallo de MOBIKE aparece no rexistro do cliente como unha reautenticación completa en lugar dunha actualización silenciosa do enderezo. O que mide é se o túnel sobrevive ao cambio, non se o protocolo anuncia compatibilidade.
Os clientes de OpenVPN reconéctanse segundo o comportamento da súa plataforma e os temporizadores do perfil, así que a mesma proba pode producir unha interrupción de forma distinta. Compare o evento que importa aos seus usuarios, non a etiqueta do protocolo.
As credenciais pertencen ao servizo, non á pila
Os certificados e outras formas de inicio de sesión pertencen ao servizo que remata a conexión. Unha petición de contrasinal nun cliente non di nada sobre a compatibilidade con outro, e un perfil que funciona contra outra pasarela non di nada sobre esta. Manteña intactas as regras de identidade do servidor mentres compara as dúas pilas. Cambiar de protocolo antes de ter identificado o fallo adoita producir un segundo perfil incompatible.
Inspeccione a credencial que presentará o cliente antes de culpar a calquera dos dous protocolos, porque un certificado caducado ou mal emitido falla igual en ambos. A saída seguinte mostra o suxeito, o emisor e as datas de validez sen ler a clave privada.
openssl x509 -in client.crt -noout -subject -issuer -dates
Para unha conexión de empresa, use o método que publica a empresa e deixe de tratar a comparación como un experimento. Se compara as dúas pola súa conta, primeiro comprobe se ambas as opcións rematan nunha soa pasarela, porque ese único detalle decide canto do seu resultado trata do protocolo. Un rexeitamento que nomea a credencial é un problema de credenciais, e ningún cambio de protocolo o reparará.
Comprobe que encamiña realmente o túnel
Tras conectar, confirme que a ruta que necesita existe e que os nomes se resolven. Un perfil que existe para recursos internos pode deixar a navegación normal pola ruta local por deseño, e iso é unha decisión de política e non unha avaría. O importante é se os destinos que usa o seu equipo son alcanzables a través do túnel.
Dous comandos cobren a ruta e a consulta de nomes en Windows. Os equivalentes en Linux son ip route show default e resolvectl query <internal-host>.
Get-NetRoute -DestinationPrefix 0.0.0.0/0
Resolve-DnsName <internal-host>
Un túnel que sobe e non encamiña nada útil é un resultado habitual cando un perfil se copiou entre servizos, e unha proba de conectividade xenérica non o mostrará porque a interface está activa. Probe o recurso que os seus usuarios abren primeiro, non un enderezo público que calquera ruta pode alcanzar. Se o nome se resolve nun enderezo público mentres a ruta apunta dentro do túnel, a resposta DNS e a ruta pertencen a decisións distintas e ambas deben corrixirse.
Sopese o mantemento despois das comprobacións
Ningún dos dous protocolos é máis mantible en abstracto. O mantemento depende de quen opera a pasarela, de como chegan os perfís aos dispositivos e da rapidez con que un dispositivo perdido perde o acceso. Un cliente de extremo sinxelo pode estar diante dun servidor máis difícil de operar, e o contrario tamén ocorre. Pregunte cal dos dous pode o seu equipo manter funcionando despois de que se vaia a persoa que o construíu.
Escolla a conexión compatible que cubra o traballo e logo probea contra o acceso que realmente necesita en lugar de contra unha lista de funcións. Anote en que pasarela remata cada opción, porque dúas pasarelas distintas fan que a comparación sexa tanto de rutas como de protocolos. Repita as catro comprobacións no dispositivo que de verdade levará, e quede co perfil que pase nel.