El par IPsec entrant no coincideix amb cap perfil? Reviseu quatre camps

El vostre par informa que el túnel està aixecat, el vostre costat no mostra cap associació de seguretat i el fitxer de configuració conté clarament un nom de connexió coincident. Aquestes tres afirmacions poden ser totes certes. Una negociació entrant es compara amb la configuració en execució, fent servir l'adreça del par, la identitat que presenta i el trànsit que proposa. Un fitxer al disc que mai no s'ha carregat, una identitat que no coincideix amb el valor esperat o una parella de selectors desviada en un prefix produiran silenci cadascun. Recorreu els quatre grups de camps en l'ordre en què ho fa el responedor.

Comenceu pel paquet, no pel fitxer

El responedor rep una sol·licitud IKE, busca una definició que pugui acceptar aquest par i després continua amb l'autenticació i la selecció de trànsit. Si cap definició carregada no coincideix en el primer pas, la negociació acaba abans que cap error útil arribi a l'usuari.

Per això «la configuració sembla correcta» no és cap prova. La pregunta és què ha carregat el servei en execució i quina entrada ha triat per a aquest intent. Un llistat d'estat ho respon amb una ordre, mentre que el búfer de l'editor respon una altra pregunta. Reviseu el llistat abans de tornar a canviar el fitxer.

Primer grup de camps: la definició que realment està carregada

Reviseu l'estat en execució amb l'eina que és propietària del dimoni: una ordre d'estat que llisti les connexions carregades, no el búfer de l'editor. Confirmeu que l'entrada que espereu hi és, que està habilitada per al comportament d'inici que voleu i que es va carregar després de la vostra última edició. Un fitxer desat que no s'ha recarregat és la causa més habitual de «ho he arreglat i no ha canviat res».

Confirmeu també quin fitxer llegeix el servei. Les distribucions difereixen, i una connexió escrita a la inclusió equivocada s'ignora en silenci en lloc de ser rebutjada. Si el llistat d'estat no mostra la vostra entrada, sospiteu de la ruta d'inclusió abans que de la sintaxi.

Segon grup de camps: els extrems no són identitats

L'adreça des de la qual es connecta el par i la identitat amb què s'autentica són camps separats. Un nom d'amfitrió, un nom distingit, un identificador de clau i una adreça poden servir tots com a identitat IKE segons la configuració, i no cal que s'assemblin gens a l'adreça pública.

La comparació d'extrems pot implicar també una visió NAT: l'adreça vista a la xarxa pot diferir de l'adreça que el par creu que té. En el model de connexions de libreswan, left i right són etiquetes dels dos participants i no un ordre fix de local i remot, i per això copiar una configuració que funciona d'un altre lloc i intercanviar les adreces no és una traducció fiable.

Anoteu la identitat esperada de cada costat i la credencial que la valida. Si aquestes dues línies no coincideixen, cap quantitat de retoc d'adreces no produirà una coincidència.

Tercer grup de camps: el trànsit que es protegeix

Els selectors descriuen els rangs interns d'origen i destinació, la seva família d'adreces i qualsevol restricció de protocol o port. Una proposta per a l'adreça d'un sol amfitrió no és la mateixa sol·licitud que per a una subxarxa sencera, i un responedor configurat per a la subxarxa pot rebutjar-la o reduir-la.

Quan els dos extrems no coincideixen, compareu el flux previst des de tots dos punts de vista en lloc d'ampliar cada selector perquè alguna cosa connecti. Pregunteu a cada administrador quin flux creu que protegeix i després compareu les dues respostes. La discrepància sol ser un prefix d'amfitrió en un costat i una subxarxa a l'altre. Un túnel que coincideix perquè ara ho protegeix tot és una decisió de seguretat diferent, i que ningú no ha aprovat.

Quart grup de camps: esteu llegint una implementació

Libreswan, Openswan antic i strongSwan tenen eines de gestió diferents, sintaxi de configuració diferent i ordre de coincidència diferent. Un exemple que funciona en un no diu res precís sobre la prioritat de selecció de perfil o la redacció d'errors d'un altre, així que verifiqueu amb la documentació del dimoni d'aquest amfitrió.

Correlacioneu un intent de cap a cap: l'adreça d'origen de l'iniciador, la identitat oferta i els selectors proposats, contra el missatge de selecció del responedor i l'entrada carregada que anomena. Els comptadors d'encapsulament i desencapsulament a zero només diuen que les associacions observades no han portat aquests paquets; no anomenen l'extrem que va rebutjar la proposta ni proven que hi hagués una entrada coincident en aquell moment.

Després d'una correcció coordinada, confirmeu el perfil i l'associació seleccionats i després proveu el servei realment permès i el seu camí de resposta. Una coincidència de perfil habilita la negociació, i la negociació no és l'última comprovació d'accés.