Xifres de Windows i strongSwan: encaixeu la capa correcta
Que les longituds de clau coincideixin no vol dir un conjunt compatible. Separeu la política IKE de les transformacions ESP i manteniu CBC i GCM en propostes diferents.
Tots dos extrems diuen AES-128 i el túnel continua negant-se a construir-se. CBC i GCM són transformacions diferents que casualment comparteixen una longitud de clau, i un client que n'ofereix una no satisfà una passarel·la que només accepta l'altra. La paraula AES descriu una família, no un acord.
També hi ha un segon eix, i és el que produeix errors confusos.
Dues capes, dues llistes independents
IKE protegeix la negociació en si, mentre que l'associació filla protegeix el trànsit que realment t'importa. Windows exposa la primera com a mètode de xifratge i mètode d'integritat, i la segona com a constants de transformació de xifratge i autenticació. Aquests camps no són àlies l'un de l'altre, i un valor vàlid en un pot ser sense sentit o incorrecte en l'altre. Llegir el perfil amb aquesta divisió al cap elimina la major part de la confusió.
La conseqüència pràctica és que pots tenir una política d'intercanvi de claus perfectament acceptable i una política de canal de dades que el par no acceptarà. Una llista negocia; l'altra protegeix paquets. Canviar un valor en la primera no té cap efecte sobre la segona, per molt semblants que semblin les dues en un diàleg de configuració.
Escriu les dues llistes abans de comparar-les amb la passarel·la. Una comparació feta de memòria és com un camp s'edita dues vegades i l'altre mai. Mantingues la consola de la passarel·la oberta al costat del perfil.
Llegeix l'error al costat de les propostes
L'etapa que ha fallat t'indica quina llista has d'examinar. Un rebuig durant l'intercanvi de claus inicial és un problema de proposta IKE, i passa abans que existeixi cap associació filla. Una fallada mentre es negocia l'associació de trànsit protegit és un problema de proposta ESP, i l'intercanvi de claus ja ha tingut èxit. Un missatge genèric de coincidència de política del client no anomena cap de les dues etapes, per això la visió pròpia de la passarel·la és la útil.
swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 60 --no-pager
Compareu la proposta rebuda, la proposta configurada i la seleccionada per a aquest intent concret. Aquí importen tres llistes diferents, i només l'última descriu què s'ha fet servir realment. Citeu-la textualment al tiquet en lloc de resumir-la.
Manteniu CBC i GCM com a alternatives separades
Una passarel·la a la qual es permet deliberadament acceptar qualsevol de les dues famílies necessita dues propostes, no una. A strongSwan una coma separa alternatives, i un guionet uneix els components d'un sol conjunt. Combinar les dues famílies amb guionets produeix una proposta impossible en lloc de dues d'acceptables.
proposals = aes128gcm16-prfsha256-ecp256, aes128-sha256-ecp256
esp_proposals = aes128gcm16-ecp256
La primera alternativa porta xifratge autenticat i encara anomena una funció pseudoaleatòria, perquè la derivació de claus en necessita una fins i tot quan la integritat ve del xifratge. La segona alternativa és xifratge clàssic amb un algorisme d'integritat separat. Totes dues continuen subjectes al que admet la implementació criptogràfica carregada.
Una proposta ESP no és una proposta IKE reanomenada
El testimoni de xifratge sembla idèntic a les dues llistes, i gairebé res més no es trasllada. Una proposta ESP no té funció pseudoaleatòria d'intercanvi de claus, i els seus requisits d'integritat i de secret futur es defensen contra la política de Windows de l'altre costat en lloc de copiar-se de la línia IKE. Traduir mecànicament una llista a l'altra produeix una cosa que valida i mai negocia.
Tria una direcció i mantén-t'hi. O la passarel·la manté una política només GCM i el client desplega una política compatible completa, o la passarel·la accepta les dues famílies i el client manté el seu conjunt existent. Habilitar una alternativa que la política de seguretat prohibeix no és una solució, per ràpid que sigui a netejar l'error.
Verifiqueu els dos conjunts i després una renovació de claus
Confirmeu el conjunt d'intercanvi de claus seleccionat i el conjunt de trànsit seleccionat per separat, perquè vénen de llistes diferents i poden tenir èxit de manera independent. Després deixeu que es produeixi una renovació de claus i confirmeu-la també. Una primera encaixada de mans que funciona i una renovació de claus que falla descriuen un conjunt de propostes només parcialment acceptable.
Conserveu aquesta evidència amb el canvi. Una desconnexió recurrent necessita el seu propi registre d'intercanvi fallit abans que algú culpi un temporitzador o un defecte de la plataforma.