IKEv2 na Windowsu i FortiGateu: tri postavke koje ljudi spajaju

Sporazum IKEv2 između Windows klijenta i FortiGate pristupnika stalno pada, a potraga za brojem koji se ne podudara daje još duži spisak brojeva. Spisak postaje upravljiv tek kada se podijeli na tri reda koji padaju neovisno: razmjena ključeva koja štiti IKE, zaštita primijenjena na CHILD SA i autentifikacija koja dokazuje koja je strana koja. Brojevi grupa pojavljuju se u dva od tih redova i znače različite stvari.

Tri reda koja padaju neovisno

Prvi red je razmjena ključeva unutar samog IKE-a, koja stvara ključeve koji štite pregovaranje. Drugi je prijedlog za CHILD SA, koji štiti promet koji tunel prenosi. Treći je autentifikacija, koja odlučuje šta svaka strana predstavlja i kako je druga strana provjerava.

Kvarovi završavaju na različitim mjestima. Kvar razmjene zaustavlja pregovaranje prije nego što uopće postoji tunel. Kvar CHILD SA događa se nakon uspješne autentifikacije, ponekad samo pri obnovi ključeva. Kvar autentifikacije u zapisima može izgledati kao kvar razmjene ako čitate samo prvu grešku.

Razdvajanje redova nije knjigovodstvo. Ono mijenja to koja je postavka vrijedna promjene i sprječava najskuplji potez u cijelom ovom području, a to je ponovno stvaranje ispravnih certifikata radi ispravljanja neslaganja u prijedlogu. Promjena jednog reda nikada ne bi smjela prisiliti druga dva da se mijenjaju s njom. Ta neovisnost je cijela poanta njihovog odvojenog pisanja.

Šta kontroliraju dva Windows polja

Windows drži dva polja odvojeno: DHGroup konfigurira samu IKE razmjenu, dok PfsGroup konfigurira IPsec politiku koja štiti promet u tunelu. Oni pripadaju različitim fazama. Usporedba Windows IKE polja s vrijednošću faze 2 na FortiGateu provjerava pogrešan par, a brojevi se mogu podudarati dok osnovna razmjena i dalje pada.

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

Druga i treća naredba prikazuju sigurnosne asocijacije koje stvarno postoje, a to je najbliže odgovoru koji vam klijent može dati. Asocijacija glavnog načina bez asocijacije brzog načina problem je CHILD SA i to je znak neslaganja faze 2, a ne problema s certifikatom.

Zabilježite šta je ponuđeno i šta je odabrano u jednom pokušaju. Ponuđena lista koja sadrži prihvatljiv prijedlog i odabrani prijedlog koji ne odgovara politici pristupnika neslaganje je u konfiguraciji, a ne misterij interoperabilnosti.

Grupa eliptične krivulje ne bira vaš ključ za potpis

Najtvrdokorniji pogrešan zaključak u ovom području je da odabir DH grupe eliptične krivulje zahtijeva certifikat eliptične krivulje. DH grupa daje materijal za razmjenu ključeva; algoritam potpisa pregovara okvir autentifikacije, i to su dvije odvojene odluke u IKEv2.

RFC 7427 postoji upravo zato što su te odluke prije bile isprepletene, i definira kako se algoritmi potpisa oglašavaju i biraju neovisno od razmjene ključeva. Pristupnik može istovremeno podržavati grupu krivulje i izbor shema potpisa.

Zato, kada pregovaranje padne nakon promjene grupe, pogledajte metodu autentifikacije prije nego što pogledate tip ključa certifikata. Promjena certifikata spora je i rizična operacija koja je rijetko odgovor, a ako je učinite prvom, uništavate sposobnost da utvrdite koja je promjena zapravo pomogla. Pročitajte red autentifikacije prije nego što dotaknete spremište certifikata.

Držite oboje u odvojenim redovima dogovora i greška prestaje biti primamljiva. Jedan red navodi grupe, drugi navodi sheme potpisa i identitete, i nijedan nije dokaz o onom drugom.

Smjestite svaki privatni ključ kod njegovog stvarnog vlasnika

Pristupnik koji predstavlja vlastiti certifikat treba privatni ključ koji mu odgovara. Partner koji provjerava lanac treba CA certifikat i posebno mu ne treba CA-ov ključ za potpis. Miješanje tih triju artefakata način je na koji ljudi završe s uvozom privatnog CA ključa u VPN uređaj kako bi se certifikat pojavio u drugoj kategoriji.

Na FortiOS-u su uloge različite: lokalni certifikat s njegovim ključem, udaljeni certifikat koji se koristi za identifikaciju partnera i unos udaljenog CA koji uspostavlja povjerenje u certifikate koje je taj CA potpisao. Unos udaljenog CA bez privatnog ključa nije nepotpun; on je ispravan za svoju svrhu.

Uvezeni CA ključevi za potpis proširuju ovlasti svakoga ko može čitati taj uređaj. Oni također ne rješavaju uobičajenu provjeru partnera, jer provjera treba javni certifikat i odluku o povjerenju, a ne sposobnost izdavanja novih certifikata.

Držite CA ključ za potpis kod procesa samog izdavaoca i zabilježite koji uređaj drži koji ključ. Kratka tabela vlasnika vrijedi više od duže tabele algoritama kada revizija pita ko je koga mogao lažno predstavljati. Niko ne uvozi ključ za koji zna da je samo inventarski. Napišite inventar prije incidenta, a ne poslije.