O secreto de grupo de vpnc ou o teu inicio de sesión: que campo recibe que?
Un perfil de vpnc pide un ID de grupo, un secreto de grupo e un inicio de sesión XAuth, e a xente mete o contrasinal da conta na caixa equivocada. Asigna cada campo segundo a súa función.
A primeira vez que alguén che pasa un perfil de vpnc, o diálogo de credenciais pregunta catro cousas e parece que queira un só contrasinal. Non o quere: o secreto de grupo compartido de antemán e o inicio de sesión individual XAuth son valores separados con donos separados, e poñer o contrasinal da conta no campo de grupo produce un fallo que parece un contrasinal incorrecto en vez dunha caixa equivocada. Acertar co mapa é toda a tarefa aquí. O protocolo que hai debaixo é o proxecto de migración doutra persoa, polo que nada disto é un argumento para construír túneles IKEv1 novos.
Dous secretos, dous donos, un diálogo
O secreto de grupo pertence ao perfil da pasarela. Todos os que se conectan por ese perfil usan o mesmo valor, e é exactamente por iso que non pode identificar a unha persoa nin se pode retirar dun portátil sen cambialo para todos os demais usuarios do perfil. O nome de usuario e o contrasinal de XAuth pertencen á persoa, e a pasarela avalíaos nunha segunda etapa, cando a asociación IPsec xa está levantada.
Esa forma de dúas etapas é o que a xente pasa por alto. O establecemento do túnel e a autenticación do usuario son intercambios distintos con entradas distintas, así que un cliente que nunca chega ao aviso de credenciais non fallou en absoluto no inicio de sesión. Le o diálogo como dúas columnas en lugar de unha: valores de todo o perfil á esquerda, valores persoais á dereita. Cando falla unha conexión, a columna que encheches máis recentemente non é automaticamente a culpable.
Asigna os campos por función, non por etiqueta
vpnc nomea as súas directivas na documentación do proxecto, e cada interface gráfica renómaas. Traduce a función de cada valor e as etiquetas deixan de importar:
| Directive | What it carries | Who owns it |
|---|---|---|
| IPSec gateway | Address or hostname of the remote VPN endpoint | Operator |
| IPSec ID | Group identifier selecting the profile on that gateway | Operator |
| IPSec secret | Group preshared secret, not an account password | Profile, shared |
| Xauth username and password | Credentials for the per-user stage after the tunnel | Person |
Unha interface que mostra «Nome de usuario» e «Contrasinal» xunto a un campo de grupo non está mal — son os mesmos tres valores con nomes distintos. O que se rompe é encher unha caixa porque un valor encaixa nela. Un secreto de grupo pegado como contrasinal de usuario autentica o perfil e despois falla na etapa de usuario; un contrasinal de conta pegado como secreto de grupo falla antes, antes de calquera aviso, e manda á xente a mirar cortalumes por un problema que vive nun campo de texto.
Que non é un identificador de grupo
A palabra grupo invita a unha lectura equivocada. Un identificador de grupo aquí é un selector que lle di á pasarela que configuración de perfil aplicar; non di nada sobre a pertenza ao directorio, e un nome coincidente en ambos os dous lados é unha casualidade ata que o operador o confirme. A autorización ocorre despois de que XAuth teña éxito, decídea aquilo co que a pasarela estea configurada para consultar, e nada diso se ve no diálogo do cliente.
A mesma precaución se aplica ao secreto de grupo. Coñecelo non é unha identidade, e facer circular un só secreto por un equipo é unha decisión operativa con consecuencias que o cliente non che pode mostrar.
Resolve a instrución ambigua antes de conectar
As notas de traspaso herdadas adoitan conter unha liña como «usa o IP público dedicado». Esa frase pode significar o enderezo desde o que unha lista de permitidos do outro lado espera que chegue o teu tráfico, que é unha propiedade de saída da rede do operador e non ten nada que ver co punto final que escribes no campo da pasarela. Pregunta cal das dúas se quere antes de que o valor vaia a algunha parte. Enchida ao revés, envía cada paquete a un enderezo que nunca responde, e o tempo de espera resultante lese como un porto bloqueado.
Pide catro cousas pola canle verificada da organización: que cliente e protocolo se admiten, que punto final usar, que identidade presentará a pasarela e como se entregan as credenciais. Mantén os secretos reais fóra de capturas de pantalla, tickets e notas compartidas de resolución de problemas. Non desactives as comprobacións de certificados nin pegues unha lista de cifrados antiga para que un servizo configurado doutro xeito pareza compatible, porque unha conexión que só funciona debilitando a verificación non é a conexión que che pediron construír.
Mantén honesto o perfil herdado
IKEv1 está obsoleto, e RFC 9395 é o documento que se cita cando xorde a cuestión da migración. Unha asignación de campos correcta non é proba de que o protocolo pertenza a un deseño novo; o que compra é unha conexión funcional mentres se programa o substituto, máis un alcance escrito e un responsable para esa migración.
Despois verifica contra o requisito en vez de contra o diálogo. Tras conectar, confirma que a interface do túnel ten o enderezo esperado e que un destino interno se encamiña por ela; se o requisito orixinal nomeaba un enderezo de saída para unha lista de permitidos, confirma tamén ese enderezo, porque é un feito distinto do túnel estar levantado. Un perfil que se autentica correctamente e non encamiña nada fallou igualmente a tarefa para a que se creou.