IKEv2 у Windows-у и FortiGate-у: три подешавања која људи стапају
Размена кључева IKE, заштита CHILD SA и аутентификација партнера су три одвојена реда. Поклапање бројева група у два дијалога их не стапа.
Споразум IKEv2 између Windows клијента и FortiGate гејтвеја стално не успева, а потрага за бројем који се не поклапа даје још дужи списак бројева. Списак постаје управљив тек када се подели на три реда који не успевају независно: размена кључева која штити IKE, заштита примењена на CHILD SA и аутентификација која доказује која је страна која. Бројеви група се појављују у два од тих редова и значе различите ствари.
Три реда која не успевају независно
Први ред је размена кључева унутар самог IKE-а, која ствара кључеве који штите преговарање. Други је предлог за CHILD SA, који штити саобраћај који тунел преноси. Трећи је аутентификација, која одлучује шта свака страна представља и како је друга страна проверава.
Откази завршавају на различитим местима. Отказ размене зауставља преговарање пре него што уопште постоји тунел. Отказ CHILD SA дешава се након успешне аутентификације, понекад само при обнови кључева. Отказ аутентификације у записима може изгледати као отказ размене ако читате само прву грешку.
Раздвајање редова није књиговодство. Оно мења то која је поставка вредна промене и спречава најскупљи потез у целом овом подручју, а то је поновно стварање исправних сертификата ради исправљања неспагања у предлогу. Промена једног реда никада не би смела да присили друга два да се мењају с њом. Та независност је цела поента њиховог одвојеног писања.
Шта контролишу два Windows поља
Windows држи два поља одвојено: DHGroup конфигурише саму IKE размену, док PfsGroup конфигурише IPsec политику која штити саобраћај у тунелу. Они припадају различитим фазама. Поређење Windows IKE поља са вредношћу фазе 2 на FortiGate-у проверава погрешан пар, а бројеви се могу подударати док основна размена и даље не успева.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSAДруга и трећа наредба приказују безбедносне асоцијације које стварно постоје, а то је најближе одговору који вам клијент може дати. Асоцијација главног режима без асоцијације брзог режима је проблем CHILD SA и то је знак неспагања фазе 2, а не проблема с сертификатом.
Забележите шта је понуђено и шта је изабрано у једном покушају. Понуђена листа која садржи прихватљив предлог и изабрани предлог који не одговара политици гејтвеја неслагање је у конфигурацији, а не мистерија интероперабилности.
| 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 |
Група елиптичне криве не бира ваш кључ за потпис
Најтврдоглавији погрешан закључак у овом подручју је да избор DH групе елиптичне криве захтева сертификат елиптичне криве. DH група даје материјал за размену кључева; алгоритам потписа преговара оквир аутентификације, и то су две одвојене одлуке у IKEv2.
RFC 7427 постоји управо зато што су те одлуке раније биле испреплетене, и дефинише како се алгоритми потписа оглашавају и бирају независно од размене кључева. Гејтвеј може истовремено да подржава групу криве и избор шема потписа.
Зато, када преговарање не успе после промене групе, погледајте методу аутентификације пре него што погледате тип кључа сертификата. Промена сертификата је спора и ризична операција која је ретко одговор, а ако је учините првом, уништавате способност да утврдите која је промена заиста помогла. Прочитајте ред аутентификације пре него што дотакнете спремиште сертификата.
Држите обоје у одвојеним редовима споразума и грешка престаје да буде примамљива. Један ред наводи групе, други наводи шеме потписа и идентитете, и ниједан није доказ о оном другом.
Сместите сваки приватни кључ код његовог стварног власника
Гејтвеј који представља сопствени сертификат треба приватни кључ који му одговара. Партнер који проверава ланац треба CA сертификат и посебно му не треба CA-ов кључ за потпис. Мешање тих трију артефаката је начин на који људи увозе приватни CA кључ у VPN уређај како би се сертификат појавио у другој категорији.
На FortiOS-у су улоге различите: локални сертификат с његовим кључем, удаљени сертификат који се користи за идентификацију партнера и запис удаљеног CA који успоставља поверење у сертификате које је тај CA потписао. Запис удаљеног CA без приватног кључа није непотпун; он је исправан за своју сврху.
Увезени CA кључеви за потпис проширују овлашћења свакога ко може да чита тај уређај. Они такође не решавају уобичајену проверу партнера, јер провера треба јавни сертификат и одлуку о поверењу, а не способност издавања нових сертификата.
Држите CA кључ за потпис код процеса самог издаваоца и забележите који уређај држи који кључ. Кратка табела власника вреди више од дуже табеле алгоритама када ревизија пита ко је кога могао да глуми. Нико не увози кључ за који зна да је само инвентарски. Напишите инвентар пре инцидента, а не после.