IKEv2 në Windows dhe FortiGate: tre cilësime që njerëzit i bashkojnë
Shkëmbimi i çelësave IKE, mbrojtja e CHILD SA dhe vërtetimi i palës janë tre rreshta të veçantë. Numrat e njëjtë të grupit në dy dritare nuk i bashkojnë.
Marrëveshja IKEv2 midis një klienti Windows dhe një portiku FortiGate vazhdon të dështojë, dhe kërkimi i një numri që nuk përputhet prodhon një listë edhe më të gjatë numrash. Lista bëhet e menaxhueshme vetëm kur ndahet në tre rreshta që dështojnë në mënyrë të pavarur: shkëmbimi i çelësave që mbron IKE, mbrojtja e aplikuar në CHILD SA dhe vërtetimi që provon kush është secila palë. Numrat e grupit shfaqen në dy prej atyre rreshtave dhe kanë kuptime të ndryshme.
Tre rreshta që dështojnë në mënyrë të pavarur
Rreshti i parë është shkëmbimi i çelësave brenda vetë IKE, i cili prodhon çelësat që mbrojnë negociatën. I dyti është propozimi për CHILD SA, i cili mbron trafikun që transporton tuneli. I treti është vërtetimi, i cili vendos çfarë paraqet secila palë dhe si e vërteton pala tjetër.
Dështimet ndodhin në vende të ndryshme. Një dështim i shkëmbimit e ndalon negociatën përpara se të ekzistojë ndonjë tunel. Një dështim i CHILD SA ndodh pasi vërtetimi ka sukses, ndonjëherë vetëm në një rinovim çelësash. Një dështim i vërtetimit mund të duket në regjistra si dështim i shkëmbimit nëse lexoni vetëm gabimin e parë.
Ndarja e rreshtave nuk është kontabilitet. Ndryshon cilën cilësim ia vlen të ndryshosh dhe parandalon lëvizjen më të kushtueshme në gjithë këtë fushë, përkatësisht rigjenerimin e certifikatave funksionale për të rregulluar një mospërputhje propozimi. Ndryshimi i një rreshti nuk duhet të detyrojë kurrë dy të tjerët të ndryshojnë bashkë me të. Kjo pavarësi është i gjithë qëllimi i shkrimit të tyre veçmas.
Çfarë kontrollojnë dy fushat e Windows
Windows mban dy fusha të ndara: DHGroup konfiguron vetë shkëmbimin IKE, ndërsa PfsGroup konfiguron politikën IPsec që mbron trafikun brenda tunelit. Ato i përkasin fazave të ndryshme. Krahasimi i një fushe IKE të Windows me një vlerë të fazës 2 të FortiGate teston çiftin e gabuar, dhe numrat mund të përputhen ndërsa shkëmbimi themelor vazhdon të dështojë.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSAKomanda e dytë dhe e tretë raportojnë shoqatat e sigurisë që ekzistojnë vërtet, dhe kjo është gjëja më e afërt me një përgjigje që një klient mund t'ju japë. Një shoqatë në modalitetin kryesor pa një shoqatë në modalitetin e shpejtë është problem i CHILD SA, dhe është shenja e një mospërputhjeje të fazës 2 dhe jo e një problemi certifikate.
Shënoni çfarë u ofrua dhe çfarë u zgjodh në një përpjekje. Një listë e ofruar që përmban një propozim të pranueshëm dhe një propozim i zgjedhur që nuk përputhet me politikën e portikut është një mosmarrëveshje konfigurimi, jo një mister ndërveprimi.
| 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 |
Një grup kurbë eliptike nuk zgjedh çelësin tuaj të nënshkrimit
Konkluzioni i gabuar më këmbëngulës në këtë fushë është se zgjedhja e një grupi DH me kurbë eliptike kërkon një certifikatë me kurbë eliptike. Një grup DH siguron material për shkëmbimin e çelësave; algoritmi i nënshkrimit negociohet nga korniza e vërtetimit, dhe këto janë dy vendime të veçanta në IKEv2.
RFC 7427 ekziston pikërisht sepse ato vendime ishin më parë të ndërthurura, dhe përcakton si algoritmet e nënshkrimit shpallen dhe zgjidhen në mënyrë të pavarur nga shkëmbimi i çelësave. Një portik mund të mbështesë njëkohësisht një grup kurbe dhe një zgjedhje skemash nënshkrimi.
Prandaj, kur një negociatë dështon pas një ndryshimi grupi, shikoni metodën e vërtetimit përpara se të shikoni llojin e çelësit të certifikatës. Ndryshimi i një certifikate është një operacion i ngadaltë dhe i rrezikshëm që rrallë është përgjigja, dhe kryerja e tij e para shkatërron aftësinë tuaj për të kuptuar se cili ndryshim ndihmoi vërtet. Lexoni rreshtin e vërtetimit përpara se të prekni depon e certifikatave.
Mbajini të dyja në rreshta të veçantë të fletës së marrëveshjes dhe gabimi pushon së qeni joshës. Një rresht rendit grupet, tjetri rendit skemat e nënshkrimit dhe identitetet, dhe asnjëri nuk është provë për tjetrin.
Vendosni çdo çelës privat pranë pronarit të tij të vërtetë
Një portik që paraqet certifikatën e vet ka nevojë për çelësin privat që i përgjigjet. Një palë që vërteton një zinxhir ka nevojë për certifikatën e CA dhe në mënyrë specifike nuk ka nevojë për çelësin e nënshkrimit të CA. Ngatërrimi i këtyre tre artefakteve është mënyra se si njerëzit përfundojnë duke importuar një çelës privat CA në një pajisje VPN për të bërë që një certifikatë të shfaqet në një kategori tjetër.
Në FortiOS rolet janë të dallueshme: një certifikatë lokale me çelësin e saj, një certifikatë e largët e përdorur për të identifikuar një palë dhe një zë CA e largët që vendos besimin në certifikatat që nënshkroi ajo CA. Një zë CA e largët pa çelës privat nuk është e paplotë; është e saktë për qëllimin e saj.
Çelësat e nënshkrimit të CA të importuar zgjerojnë autoritetin e kujtdo që mund të lexojë atë pajisje. Gjithashtu nuk zgjidhin vërtetimin e zakonshëm të palës, sepse vërtetimi ka nevojë për certifikatën publike dhe vendimin e besimit, jo për aftësinë për të lëshuar certifikata të reja.
Mbajeni çelësin e nënshkrimit të CA pranë procesit të vetë lëshuesit dhe shënoni cila pajisje mban cilin çelës. Një tabelë e shkurtër pronarësh vlen më shumë se një tabelë më e gjatë algoritmesh kur një auditim pyet kush mund të kishte shtirur si kush. Askush nuk importon një çelës që e di se është vetëm inventar. Shkruani inventarin përpara incidentit, jo pas tij.