Os dous nomes aparecen xuntos no mesmo menú despregable, o que invita a escoller entre iguais. Non son iguais. L2TP é un protocolo de túnel sen confidencialidade propia, e a protección dun servizo L2TP/IPsec vén da capa IPsec que o envolve. IKEv2 negocia directamente unha asociación IPsec e non ten ningún paso de túnel dentro de túnel. Saber que pila ofrece o teu servidor decide o perfil, os avisos e o que acontece cando o portátil cambia de rede.

Dúas pilas, unha etiqueta no cliente

L2TP transporta unha sesión punto a punto sobre UDP ata o porto 1701 e deixa o cifrado a quen o envolve. Combínao con IPsec e obtés dúas capas: unha asociación IPsec que protexe o camiño e, dentro, unha sesión L2TP que leva as tramas de capa de enlace do usuario e a autenticación PPP.

IKEv2 crea unha asociación de control e despois unha ou varias asociacións fillas que protexen o tráfico, todo nunha soa familia de intercambios sobre UDP 500 e 4500. Non hai protocolo de túnel interno nin negociación PPP.

Credenciais: tres segredos repartidos en tres capas

Aquí é onde desaparece a maior parte do tempo de soporte. Un perfil L2TP/IPsec pode pedir unha chave precompartida para a capa IPsec e un nome de usuario con contrasinal para a sesión PPP interior, e as dúas cousas compróbanas compoñentes distintos. A chave compartida pertence á pasarela no seu conxunto, así que non identifica a ninguén; só demostra que o par coñece un segredo.

IKEv2 adoita usar certificados, ou EAP con nome de usuario e contrasinal, e tamén pode usar unha chave precompartida. Esas opcións non son intercambiables co par L2TP. Un restablecemento de contrasinal que arranxa un inicio de sesión EAP rexeitado non fai nada por un certificado de cliente caducado, e por moito que reescribas o contrasinal da conta nunca satisfarás unha chave de pasarela equivocada. Cando apareza un aviso que non esperabas, pregunta ao operador a que capa pertence antes de adiviñar.

QuestionL2TP/IPsecIKEv2
What encrypts the trafficA wrapping IPsec associationThe child association
Ports you must permitUDP 500/4500 and UDP 1701 insideUDP 500 and 4500
Typical secretsGateway PSK plus PPP credentialsCertificate, EAP, or PSK
Address changeTunnel breaks, reconnect neededCan migrate with MOBIKE

Que cambia MOBIKE e que non

IKEv2 pode mover unha asociación a un enderezo novo cando ambos os extremos admiten MOBIKE, o que cobre o caso dun portátil que pasa do wifi ao punto de acceso dun teléfono sen desmontar a asociación de seguridade.

Non mantén vivas todas as aplicacións durante ese movemento. O fluxo de transporte cambia igualmente de enderezo, os sockets ligados ao anterior rompen igualmente, e unha política que fixa o tráfico a unha interface pode descartalo igualmente. Proba a transición que fas de verdade, tanto se é saír dunha rede, espertar do repouso ou volver tras un período longo de inactividade, e mira a aplicación en lugar da etiqueta Conectado.

Formas de fallo que os separan

Un perfil L2TP/IPsec que chega á pasarela e se detén tende a fallar nun de dous avisos: a chave compartida ou as credenciais PPP. Unha chave equivocada normalmente non mostra nada de útil no rexistro do cliente, mentres que un contrasinal equivocado produce un rexeitamento de autenticación explícito, e esa diferenza dixe onde mirar.

Un perfil IKEv2 falla antes e máis ruidosamente cando a identidade ou o certificado son incorrectos, porque a asociación de control nunca se completa. Se a asociación se completa e o tráfico segue fallando, o problema trasladouse á asociación filla, aos selectores de tráfico ou á ruta, e ningún cambio de credenciais axudará.

Onde aínda encaixa cada un

L2TP/IPsec persiste porque está presente en case todos os clientes e non precisa software adicional, o que importa a un técnico externo nun dispositivo que non administras. O prezo é a capa extra, o modelo de segredo compartido e unha reconexión tras cada cambio de enderezo.

IKEv2 encaixa mellor en dispositivos xestionados: identidade por certificado, mobilidade máis limpa e unha soa familia de asociacións sobre a que razoar. Tamén falla con máis dureza cando o cliente é antigo, así que comproba o método de autenticación admitido pola plataforma antes de deseñar ao seu redor.

Probar o perfil que che deron

Confirma primeiro o modo no lado do servidor e despois escolle o perfil de cliente que encaixe con el. Proba co nome de host e as credenciais exactos emitidos para ese perfil, e verifica o recurso privado en lugar dun sitio público.

Se conecta e non carga nada, o túnel funciona e a ruta, o DNS ou o selector de tráfico non. Cambiar de protocolo nese punto reinicia o diagnóstico en vez de facelo avanzar.

Artigos relacionados