IKEv2 a Windows i FortiGate: tres paràmetres que la gent fusiona
L'intercanvi de claus IKE, la protecció de la CHILD SA i l'autenticació de l'igual són tres files separades. Fer coincidir els números de grup en dos diàlegs no les fusiona.
L'acord IKEv2 entre un client Windows i una passarel·la FortiGate continua fallant, i la cerca d'un número que no coincideix produeix una llista de números encara més llarga. La llista només es torna manejable quan es divideix en tres files que fallen de manera independent: l'intercanvi de claus que protegeix IKE, la protecció aplicada a la CHILD SA i l'autenticació que demostra qui és cada part. Els números de grup apareixen en dues d'aquestes files i signifiquen coses diferents.
Tres files que fallen de manera independent
La primera fila és l'intercanvi de claus dins del mateix IKE, que genera les claus que protegeixen la negociació. La segona és la proposta per a la CHILD SA, que protegeix el trànsit que transporta el túnel. La tercera és l'autenticació, que decideix què presenta cada part i com ho valida l'altra.
Els errors es produeixen en llocs diferents. Un error d'intercanvi atura la negociació abans que existeixi cap túnel. Un error de la CHILD SA passa després que l'autenticació tingui èxit, de vegades només en una renegociació de claus. Un error d'autenticació pot semblar un error d'intercanvi als registres si només llegiu el primer error.
Separar les files no és comptabilitat. Canvia quin paràmetre val la pena canviar i evita el moviment més car de tot aquest àmbit, que és regenerar certificats que funcionen per arreglar una discrepància de proposta. Que una fila canviï no hauria de forçar mai les altres dues a canviar amb ella. Aquesta independència és tot l'objectiu d'escriure-les per separat.
Què controlen els dos camps de Windows
Windows manté dos camps separats: DHGroup configura el mateix intercanvi IKE, mentre que PfsGroup configura la política IPsec que protegeix el trànsit del túnel. Pertanyen a fases diferents. Comparar un camp IKE de Windows amb un valor de fase 2 de FortiGate prova la parella equivocada, i els números poden coincidir mentre l'intercanvi subjacent continua fallant.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSALa segona i la tercera ordres informen de les associacions de seguretat que existeixen realment, que és el més a prop d'una resposta que un client us pot donar. Una associació de mode principal sense cap associació de mode ràpid és un problema de la CHILD SA, i és la signatura d'una discrepància de fase 2 més que no pas d'un problema de certificat.
Anoteu què es va oferir i què es va seleccionar en un intent. Una llista oferta que conté una proposta acceptable i una proposta seleccionada que no coincideix amb la política de la passarel·la és un desacord de configuració, no un misteri d'interoperabilitat.
| Agreement row | Where it is configured in Windows | What it does not decide |
|---|---|---|
| IKE key exchange | DHGroup on the VPN connection IPsec settings | The protection used for tunneled traffic |
| CHILD SA protection | PfsGroup in the same policy object | Which certificate the peer presents |
| Peer authentication | Machine or user certificate, or a supported EAP method | Any group number used for key exchange |
| Certificate validation | Trusted CA store on the validating side | The private key of the certificate being presented |
Un grup de corba el·líptica no tria la vostra clau de signatura
La inferència errònia més persistent en aquest àmbit és que triar un grup DH de corba el·líptica requereix un certificat de corba el·líptica. Un grup DH proporciona material per a l'intercanvi de claus; l'algorisme de signatura el negocia el marc d'autenticació, i són dues decisions separades a IKEv2.
RFC 7427 existeix precisament perquè aquestes decisions abans estaven entrellaçades, i defineix com s'anuncien i es trien els algorismes de signatura independentment de l'intercanvi de claus. Una passarel·la pot admetre alhora un grup de corba i una tria d'esquemes de signatura.
Per tant, quan una negociació falla després d'un canvi de grup, mireu el mètode d'autenticació abans de mirar el tipus de clau del certificat. Canviar un certificat és una operació lenta i arriscada que poques vegades és la resposta, i fer-ho primer destrueix la vostra capacitat de saber quin canvi va ajudar de debò. Llegiu la fila d'autenticació abans de tocar el magatzem de certificats.
Manteniu les dues coses en files separades del full d'acord i l'error deixarà de ser temptador. Una fila llista grups, l'altra llista esquemes de signatura i identitats, i cap de les dues no és evidència sobre l'altra.
Poseu cada clau privada amb el seu propietari real
Una passarel·la que presenta el seu propi certificat necessita la clau privada que hi coincideix. Un igual que valida una cadena necessita el certificat de la CA i, concretament, no necessita la clau de signatura de la CA. Confondre aquests tres artefactes és com la gent acaba important una clau privada de CA en un dispositiu VPN per fer que un certificat aparegui en una categoria diferent.
A FortiOS els papers són diferents: un certificat local amb la seva clau, un certificat remot utilitzat per identificar un igual i una entrada de CA remota que estableix confiança en els certificats que aquesta CA va signar. Una entrada de CA remota sense clau privada no és incompleta; és correcta per a la seva finalitat.
Les claus de signatura de CA importades amplien l'autoritat de qualsevol que pugui llegir aquest dispositiu. També no resolen la validació ordinària de l'igual, perquè la validació necessita el certificat públic i la decisió de confiança, no la capacitat d'emetre certificats nous.
Manteniu la clau de signatura de la CA amb el procés del mateix emissor, i anoteu quin dispositiu té quina clau. Una taula curta de propietaris val més que una taula més llarga d'algorismes quan una auditoria pregunta qui podria suplantar qui. Ningú no importa una clau que sap que només és d'inventari. Escriviu l'inventari abans de l'incident, no després.