Identidade IKE ou enderezo de extremo: non as confundas
Unha identidade IKE de tipo FQDN é un valor de autenticación literal, non unha consulta de DNS inverso. Mantén separados o enderezo do extremo, a identidade local e o peer esperado.
Le un campo etiquetado como identidade FQDN como unha cadea literal, non como unha petición do nome de DNS inverso do teu enderezo público. No analizador de strongSwan é exactamente iso, unha cadea, e lelo nunca o resolve a un extremo. Ese feito por si só elimina a distracción máis habitual cando elixes identificadores para un peer. As comprobacións seguintes evitan que os tres valores implicados se fundan nun.
Unha etiqueta non é unha consulta
As interfaces dos fabricantes usan palabras como FQDN e hostname con laxitude, e a etiqueta dunha caixa non di nada sobre a codificación que hai detrás. Un equipo que chama a un campo Client FQDN pode enviar un FQDN, unha cadea con forma de correo ou un enderezo espido. Trata o texto e o tipo como dúas decisións separadas e rexistra ambas.
Nada dunha identidade literal require DNS. É unha afirmación que comproba o outro extremo, non un nome que a rede teña que resolver.
Tres valores separados, escritos por separado
Tres tarefas están detrás dunha soa pantalla de configuración, e fusionalas é o erro caro. Un valor é o enderezo do extremo, que decide a onde van os paquetes. Outro é a identidade local que presenta este peer, e o terceiro é a identidade que esperas do outro extremo antes de autenticalo. Escríbeos como tres liñas no ticket de cambio, porque calquera cousa menos ca iso describe unha VPN e non unha relación.
| Job | Example | What it decides |
|---|---|---|
| Where the packets go | 198.51.100.7 | The endpoint address |
| What this peer claims | gw.branch.internal | The local IKE identity |
| Who should answer | ike.hub.internal | The expected remote identity |
As identidades de exemplo deben elixirse e autorizarse como parte do despregamento. Son afirmacións que a autenticación verifica, non credenciais que fagan fiable a ningún peer, así que unha cadea que parece plausible non autoriza nada.
O tipo forma parte do valor
A referencia de identidades de strongSwan separa FQDN, valores con forma de correo, enderezos IP e outras codificacións, así que a codificación importa tanto como os caracteres. Dous dispositivos poden aceptar o mesmo texto con tipos distintos e aínda así rexeitarse. Unha nota que rexistra o valor sen o seu tipo é media configuración.
Pregunta ao fabricante que tipo envía realmente o equipo e confírmao cunha descodificación, non coa etiqueta da interface. Un tipo adiviñado é unha discrepancia agardando o próximo cambio.
Cada lado ten que satisfacer o outro
A identidade local de cada lado ten que pasar a política de autenticación do outro lado. Iso non é o mesmo que pegar unha cadea en cada caixa de identidade dos dous dispositivos, que é o atallo que produce unha configuración que ninguén pode depurar.
A autenticación con certificado engade requisitos propios, porque a identidade do certificado e as condicións de confianza están xunto á identidade IKE que escribiches. Unha coincidencia de identidade IKE por si soa non autoriza un peer con certificado.
Onde importa o DNS e que impón a túa versión
Un hostname de pasarela usado para o descubrimento si necesita DNS funcionando, e ese requisito pertence á procura do extremo e non a ningunha consulta inversa dunha identidade escrita. Mantén os dous aparte no ticket, porque un fallo de descubrimento e unha discrepancia de identidade len de forma semellante nun rexistro de cliente e repáranse en lugares distintos.
Le o analizador do produto e da versión que realmente executas antes de copiar sintaxe que forza un tipo, porque as versións antigas de strongSwan comportábanse distinto e outros fabricantes engaden restricións propias. Cando compares os dous extremos, mantén catro cousas xuntas: identidade esperada, identidade presentada, tipo e o erro de autenticación. Ese conxunto converte unha discrepancia en evidencia en lugar de nunha opinión.