OpenVPN o IKEv2: quatre comprovacions abans de triar un protocol

L’elecció entre OpenVPN i IKEv2 sovint es discuteix com una qüestió de protocol, i aquest plantejament malbarata la decisió. El que la decideix és si el vostre servidor i els vostres dispositius admeten el mateix perfil complet, i si aquest perfil sobreviu a la manera com us moveu entre xarxes. Les dues piles no es tradueixen l’una en l’altra: un fitxer OVPN no és un perfil IKEv2 amb una sintaxi diferent. Quatre comprovacions, fetes per ordre, responen la pregunta més de pressa que qualsevol taula de funcions.

Un client que falta tanca la discussió

Windows i macOS inclouen un client IKEv2, així que un perfil IKEv2 no costa res extra de desplegar-hi i hereta les opcions de subministrament que el sistema operatiu ja exposa. OpenVPN a les mateixes màquines significa un client de tercers per instal·lar, actualitzar i donar suport, i aquest client ha d’acceptar cada opció que utilitza el perfil. Compteu les plataformes que heu de cobrir abans de comparar qualsevol altra cosa, perquè una plataforma sense client operatiu no és cap punt de comparació.

A Windows, una ordre llista els perfils que ja existeixen i mostra de quin tipus és cadascun. El nom que imprimeix és el nom que utilitzen les comprovacions posteriors.

Get-VpnConnection -AllUserConnection
Get-VpnConnection -Name <profile-name> | Select-Object Name, ServerAddress, TunnelType

La indicació d’instal·lar un client és la resposta real per a la columna d’OpenVPN en aquestes plataformes, i és una tasca de desplegament i no una limitació del protocol. Cap de les dues disposicions elimina les comprovacions de confiança, la verificació d’identitat ni el manteniment. Pregunteu com es distribueixen els perfils, com es renoven les credencials i com es retira un dispositiu perdut abans de comprometre-us. Una instal·lació senzilla encara pot amagar un procés de recuperació que ningú no vol executar el cap de setmana.

La mobilitat és un paràmetre conjunt, no una promesa del protocol

IKEv2 pot utilitzar MOBIKE quan tots dos extrems l’admeten i l’activen, cosa que permet a un client mantenir el túnel mentre canvia la seva adreça. RFC 4555 defineix l’extensió, i la formulació condicional és important: un servidor que ignora la capacitat renegocia en comptes d’això. El resultat pot semblar idèntic en una transferència de fitxers i molt diferent en una trucada en directe.

Proveu la transició que de debò us importa, amb alguna cosa en marxa que pugueu observar. Manteniu ping -t <internal-host> funcionant a Windows, o el simple ping en altres sistemes, després canvieu de Wi-Fi a mòbil i observeu si hi ha buits. Una fallada de MOBIKE apareix al registre del client com una reautenticació completa en lloc d’una actualització silenciosa de l’adreça. El que mesureu és si el túnel sobreviu al canvi, no si el protocol anuncia suport.

Els clients d’OpenVPN es reconnecten segons el comportament de la seva plataforma i els temporitzadors del perfil, així que la mateixa prova pot produir una interrupció de forma diferent. Compareu l’esdeveniment que importa als vostres usuaris, no l’etiqueta del protocol.

Les credencials pertanyen al servei, no a la pila

Els certificats i altres formes d’inici de sessió pertanyen al servei que acaba la connexió. Una petició de contrasenya en un client no diu res sobre la compatibilitat amb un altre, i un perfil que funciona contra una altra passarel·la no diu res sobre aquesta. Manteniu intactes les regles d’identitat del servidor mentre compareu les dues piles. Canviar de protocol abans d’haver identificat la fallada normalment produeix un segon perfil incompatible.

Inspeccioneu la credencial que presentarà el client abans de culpar cap dels dos protocols, perquè un certificat caducat o emès malament falla de la mateixa manera en tots dos. La sortida següent mostra el subjecte, l’emissor i les dates de validesa sense llegir la clau privada.

openssl x509 -in client.crt -noout -subject -issuer -dates

Per a una connexió d’empresa, feu servir el mètode que publica l’empresa i deixeu de tractar la comparació com un experiment. Si compareu les dues opcions per a vosaltres, primer comproveu si totes dues acaben en una sola passarel·la, perquè aquest detall decideix quant del vostre resultat tracta del protocol. Un rebuig que anomena la credencial és un problema de credencial, i cap canvi de protocol no el repararà.

Comproveu què encamina realment el túnel

Després de connectar-vos, confirmeu que la ruta que necessiteu existeix i que els noms es resolen. Un perfil que existeix per a recursos interns pot deixar la navegació habitual pel camí local per disseny, i això és una decisió de política i no una avaria. L’important és si els destins que utilitza el vostre equip són abastables a través del túnel.

Dues ordres cobreixen la ruta i la consulta de noms a Windows. Els equivalents a Linux són ip route show default i resolvectl query <internal-host>.

Get-NetRoute -DestinationPrefix 0.0.0.0/0
Resolve-DnsName <internal-host>

Un túnel que puja i no encamina res d’útil és un resultat habitual quan un perfil s’ha copiat entre serveis, i una prova de connectivitat genèrica no ho mostrarà perquè la interfície està activa. Proveu el recurs que els vostres usuaris obren primer, no una adreça pública que qualsevol camí pot assolir. Si el nom es resol a una adreça pública mentre la ruta apunta dins del túnel, la resposta DNS i la ruta pertanyen a decisions diferents i totes dues s’han de corregir.

Peseu el manteniment després de les comprovacions

Cap dels dos protocols no és més mantenible en abstracte. El manteniment depèn de qui opera la passarel·la, de com arriben els perfils als dispositius i de com de ràpid un dispositiu perdut perd l’accés. Un client simple d’extrem pot seure davant d’un servidor més difícil d’operar, i també passa el contrari. Pregunteu quin dels dos pot mantenir el vostre equip després que la persona que el va construir se’n vagi.

Trieu la connexió compatible que cobreix la feina i després proveu-la contra l’accés que necessiteu de debò, no contra una llista de funcions. Anoteu a quina passarel·la acaba cada opció, perquè dues passarel·les diferents fan que la comparació sigui tant de rutes com de protocols. Repetiu les quatre comprovacions al dispositiu que portareu de debò i quedeu-vos amb el perfil que hi passa.