IKEv2 на Windows и FortiGate: три поставки што луѓето ги спојуваат
Размената на клучеви IKE, заштитата на CHILD SA и автентикацијата на партнерот се три одделни редови. Совпаѓањето на броевите на групи во два дијалога не ги спојува.
Договорот IKEv2 помеѓу клиент на Windows и порта FortiGate сѐ уште не успева, а барањето на неусогласен број дава уште подолг список на броеви. Списокот станува управлив само кога ќе се подели на три реда што не успеваат независно: размената на клучеви што го штити IKE, заштитата применета на CHILD SA и автентикацијата што докажува која страна е која. Броевите на групи се појавуваат во два од тие редови и значат различни работи.
Три реда што не успеваат независно
Првиот ред е размената на клучеви во самиот IKE, која ги создава клучевите што ја штитат преговарачката постапка. Вториот е предлогот за CHILD SA, кој го штити сообраќајот што го пренесува тунелот. Третиот е автентикацијата, која одлучува што презентира секоја страна и како другата го валидира тоа.
Неуспесите паѓаат на различни места. Неуспехот на размената ја запира преговарачката постапка пред воопшто да постои тунел. Неуспехот на CHILD SA се случува откако автентикацијата ќе успее, понекогаш само при обновување на клучевите. Неуспехот на автентикацијата во дневниците може да изгледа како неуспех на размената ако ја читате само првата грешка.
Одделувањето на редовите не е книговодство. То менува која поставка вреди да се смени и го спречува најскапиот потег во целата оваа област, односно повторното генерирање на работни сертификати за да се исправи неусогласеност во предлогот. Промената на еден ред никогаш не треба да ги принуди другите два да се сменат со него. Таа независност е целата поента да се пишуваат одделно.
Што контролираат двете полиња на Windows
Windows ги држи двете полиња одделно: DHGroup ја конфигурира самата размена IKE, додека PfsGroup ја конфигурира политиката IPsec што го штити сообраќајот во тунелот. Тие припаѓаат на различни фази. Споредувањето на поле IKE на Windows со вредност за фаза 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 кај процесот на самиот издавач и запишете кој уред го држи кој клуч. Кратката табела на сопственици вреди повеќе од подолгата табела на алгоритми кога ревизијата прашува кој кого можел да имитира. Никој не внесува клуч за кој знае дека е само за инвентар. Напишете го инвентарот пред инцидентот, а не по него.