IKEv2 în Windows și FortiGate: trei setări pe care oamenii le unesc

Un acord IKEv2 între un client Windows și un gateway FortiGate continuă să eșueze, iar căutarea unui număr care nu se potrivește produce o listă și mai lungă de numere. Lista devine gestionabilă doar când este împărțită în trei rânduri care eșuează independent: schimbul de chei care protejează IKE, protecția aplicată CHILD SA și autentificarea care dovedește cine este fiecare parte. Numerele de grup apar în două dintre acele rânduri și înseamnă lucruri diferite.

Trei rânduri care eșuează independent

Primul rând este schimbul de chei din interiorul IKE însuși, care produce cheile ce protejează negocierea. Al doilea este propunerea pentru CHILD SA, care protejează traficul transportat de tunel. Al treilea este autentificarea, care decide ce prezintă fiecare parte și cum o validează cealaltă.

Eșecurile apar în locuri diferite. Un eșec al schimbului oprește negocierea înainte de a exista vreun tunel. Un eșec al CHILD SA apare după ce autentificarea reușește, uneori doar la o reînnoire de chei. Un eșec de autentificare poate arăta în jurnale ca un eșec al schimbului dacă citiți doar prima eroare.

Separarea rândurilor nu este contabilitate. Schimbă care setare merită modificată și împiedică cea mai scumpă mișcare din tot acest domeniu, și anume regenerarea certificatelor funcționale pentru a repara o nepotrivire de propunere. Modificarea unui rând nu ar trebui să oblige niciodată celelalte două să se schimbe cu el. Această independență este tot rostul scrierii lor separat.

Ce controlează cele două câmpuri din Windows

Windows ține două câmpuri separate: DHGroup configurează schimbul IKE propriu-zis, iar PfsGroup configurează politica IPsec care protejează traficul din tunel. Ele aparțin unor faze diferite. Compararea unui câmp IKE din Windows cu o valoare de faza 2 din FortiGate testează perechea greșită, iar numerele pot coincide în timp ce schimbul de bază tot eșuează.

Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSA

A doua și a treia comandă raportează asocierile de securitate care există cu adevărat, și acesta este cel mai apropiat lucru de un răspuns pe care un client ți-l poate da. O asociere în modul principal fără o asociere în modul rapid este o problemă a CHILD SA și este semnătura unei nepotriviri de faza 2, nu a unei probleme de certificat.

Notați ce a fost oferit și ce a fost selectat într-o încercare. O listă oferită care conține o propunere acceptabilă și o propunere selectată care nu corespunde politicii gateway-ului este un dezacord de configurare, nu un mister de interoperabilitate.

Un grup de curbă eliptică nu îți alege cheia de semnătură

Cea mai persistentă concluzie greșită din acest domeniu este că alegerea unui grup DH pe curbă eliptică necesită un certificat pe curbă eliptică. Un grup DH furnizează material pentru schimbul de chei; algoritmul de semnătură este negociat de cadrul de autentificare, iar acestea sunt două decizii separate în IKEv2.

RFC 7427 există exact pentru că aceste decizii erau anterior încurcate, și definește cum algoritmii de semnătură sunt anunțați și selectați independent de schimbul de chei. Un gateway poate susține simultan un grup de curbă și o alegere de scheme de semnătură.

Deci, când o negociere eșuează după o schimbare de grup, priviți metoda de autentificare înainte de a privi tipul de cheie al certificatului. Schimbarea unui certificat este o operațiune lentă și riscantă care rareori este răspunsul, iar a o face prima distruge capacitatea de a afla care modificare a ajutat cu adevărat. Citiți rândul de autentificare înainte de a atinge depozitul de certificate.

Țineți ambele în rânduri separate ale fișei de acord și greșeala încetează să mai fie tentantă. Un rând enumeră grupuri, celălalt enumeră scheme de semnătură și identități, iar niciunul nu este dovadă despre celălalt.

Puneți fiecare cheie privată lângă proprietarul ei real

Un gateway care își prezintă propriul certificat are nevoie de cheia privată care îi corespunde. Un partener care validează un lanț are nevoie de certificatul CA și, în mod specific, nu are nevoie de cheia de semnătură a CA. Confundarea acestor trei artefacte este modul în care oamenii ajung să importe o cheie privată CA într-un dispozitiv VPN pentru ca un certificat să apară într-o altă categorie.

În FortiOS rolurile sunt distincte: un certificat local cu cheia lui, un certificat la distanță folosit pentru a identifica un partener și o intrare CA la distanță care stabilește încrederea în certificatele semnate de acea CA. O intrare CA la distanță fără cheie privată nu este incompletă; este corectă pentru scopul ei.

Cheile de semnătură CA importate lărgesc autoritatea oricui poate citi acel dispozitiv. De asemenea, nu rezolvă validarea obișnuită a partenerului, pentru că validarea are nevoie de certificatul public și de decizia de încredere, nu de capacitatea de a emite certificate noi.

Țineți cheia de semnătură a CA la procesul emitentului însuși și notați ce dispozitiv deține ce cheie. Un tabel scurt de proprietari valorează mai mult decât un tabel mai lung de algoritmi atunci când un audit întreabă cine ar fi putut să se dea drept cine. Nimeni nu importă o cheie despre care știe că este doar de inventar. Scrieți inventarul înainte de incident, nu după.