¿El secreto de grupo de vpnc o tu inicio de sesión: qué campo recibe qué?

La primera vez que alguien te pasa un perfil de vpnc, el diálogo de credenciales pregunta cuatro cosas y parece que quiera una sola contraseña. No la quiere: el secreto de grupo compartido de antemano y el inicio de sesión individual XAuth son valores separados con dueños separados, y poner la contraseña de la cuenta en el campo de grupo produce un fallo que parece una contraseña incorrecta en lugar de una casilla equivocada. Acertar con el mapa es toda la tarea aquí. El protocolo que hay debajo es el proyecto de migración de otra persona, por lo que nada de esto es un argumento para construir túneles IKEv1 nuevos.

Dos secretos, dos dueños, un diálogo

El secreto de grupo pertenece al perfil de la puerta de enlace. Todos los que se conectan por ese perfil usan el mismo valor, y es exactamente por eso que no puede identificar a una persona ni puede retirarse de un portátil sin cambiarlo para todos los demás usuarios del perfil. El nombre de usuario y la contraseña de XAuth pertenecen a la persona, y la puerta de enlace los evalúa en una segunda etapa, cuando la asociación IPsec ya está levantada.

Esa forma de dos etapas es lo que la gente pasa por alto. El establecimiento del túnel y la autenticación del usuario son intercambios distintos con entradas distintas, así que un cliente que nunca llega al aviso de credenciales no ha fallado en absoluto en el inicio de sesión. Lee el diálogo como dos columnas en lugar de una: valores de todo el perfil a la izquierda, valores personales a la derecha. Cuando falla una conexión, la columna que rellenaste más recientemente no es automáticamente la culpable.

Asigna los campos por función, no por etiqueta

vpnc nombra sus directivas en la documentación del proyecto, y cada interfaz gráfica las renombra. Traduce la función de cada valor y las etiquetas dejan de importar:

Una interfaz que muestra «Nombre de usuario» y «Contraseña» junto a un campo de grupo no está mal — son los mismos tres valores con nombres distintos. Lo que se rompe es rellenar una casilla porque un valor encaja en ella. Un secreto de grupo pegado como contraseña de usuario autentica el perfil y luego falla en la etapa de usuario; una contraseña de cuenta pegada como secreto de grupo falla antes, antes de cualquier aviso, y manda a la gente a mirar cortafuegos por un problema que vive en un campo de texto.

Qué no es un identificador de grupo

La palabra grupo invita a una lectura equivocada. Un identificador de grupo aquí es un selector que le dice a la puerta de enlace qué configuración de perfil aplicar; no dice nada sobre la pertenencia al directorio, y un nombre coincidente en ambos lados es una casualidad hasta que el operador lo confirme. La autorización ocurre después de que XAuth tenga éxito, la decide aquello con lo que la puerta de enlace esté configurada para consultar, y nada de eso se ve en el diálogo del cliente.

La misma precaución se aplica al secreto de grupo. Conocerlo no es una identidad, y hacer circular un solo secreto por un equipo es una decisión operativa con consecuencias que el cliente no puede mostrarte.

Resuelve la instrucción ambigua antes de conectar

Las notas de traspaso heredadas suelen contener una línea como «usa la IP pública dedicada». Esa frase puede significar la dirección desde la que una lista de permitidos del otro lado espera que llegue tu tráfico, que es una propiedad de salida de la red del operador y no tiene nada que ver con el punto final que escribes en el campo de la puerta de enlace. Pregunta cuál de las dos se quiere antes de que el valor vaya a alguna parte. Rellenada al revés, envía cada paquete a una dirección que nunca responde, y el tiempo de espera resultante se lee como un puerto bloqueado.

Pide cuatro cosas por el canal verificado de la organización: qué cliente y protocolo se admiten, qué punto final usar, qué identidad presentará la puerta de enlace y cómo se entregan las credenciales. Mantén los secretos reales fuera de capturas de pantalla, tickets y notas compartidas de resolución de problemas. No desactives las comprobaciones de certificados ni pegues una lista de cifrados antigua para que un servicio configurado de otra manera parezca compatible, porque una conexión que solo funciona debilitando la verificación no es la conexión que te pidieron construir.

Mantén honesto el perfil heredado

IKEv1 está obsoleto, y RFC 9395 es el documento que se cita cuando surge la cuestión de la migración. Un mapeo de campos correcto no es prueba de que el protocolo pertenezca a un diseño nuevo; lo que compra es una conexión funcional mientras se programa el reemplazo, más un alcance escrito y un responsable para esa migración.

Luego verifica contra el requisito en lugar de contra el diálogo. Tras conectar, confirma que la interfaz del túnel tiene la dirección esperada y que un destino interno se enruta a través de ella; si el requisito original nombraba una dirección de salida para una lista de permitidos, confirma también esa dirección, porque es un hecho distinto del túnel estando levantado. Un perfil que se autentica correctamente y no enruta nada ha fallado igualmente la tarea para la que se creó.