IKEv2 ni eno samo rokovanje: IKE SA, avtentikacija, nato CHILD SA
Odgovor prehoda dokazuje dosegljivost, ne identiteto. Spremljajte IKE_SA_INIT, IKE_AUTH in prvi CHILD SA, nato preverite, kaj mora veljati pred prehodom prometa.
Morda mislite, da je povezava IKEv2 ena izmenjava, ki se konča s šifriranim prometom. Sta vsaj dve, prva pa nikogar ne avtenticira. Strani začneta s krmilnimi sporočili, se dogovorita o kriptografskih parametrih, dokažeta identiteto in šele nato se pogajata o stanju, ki prenaša pakete aplikacije. Ta vrstni red pojasnjuje neskladje, o katerem ljudje nenehno poročajo: prehod odgovori, odjemalec pokaže povezavo, zasebna aplikacija pa vseeno poteče. Tu je, kaj vsak korak v resnici počne in kaj mora veljati za njim.
Mit: če prehod odgovori, ste povezani
Odgovor na prvo sporočilo dokazuje, da je končna točka dosegljiva in pripravljena govoriti. Ne dokazuje, da je bil račun sprejet, da je bila veriga potrdil preverjena ali da je bila nameščena kakršna koli podatkovna politika.
Te napake se zgodijo pozneje in dajo drugačne simptome. Zavrnitev potrdila ali napaka EAP pride po tem, ko je bila prva izmenjava že uspešna, zato ping na UDP 500 in zelena ikona odjemalca povesta tako malo.
IKE_SA_INIT: dogovorite se o parametrih, ne o identiteti
Prva izmenjava prenaša predloge za varnostno združenje IKE: algoritme šifriranja in celovitosti, psevdonaključno funkcijo in skupino Diffie-Hellman. Strani si izmenjata tudi nonce, vsaka stran pa izpelje ključni material za IKE SA iz skupne skrivnosti, ki jo te vrednosti ustvarijo. Nič v tej izmenjavi ne določi, kdo je druga stran. Določi le, da lahko obe strani izračunata iste ključe in da se strinjata o enem predlogu. Odgovor, ki mu noben predlog ni všeč, izmenjavo tu zavrne, zato je neskladje različice ali algoritma videti kot mrtev strežnik.
IKE SA, ustvarjen na tej točki, ščiti vse poznejše krmilne izmenjave. To je njegova naloga in to je drugačna naloga od zaščite vaših paketov.
IKE_AUTH: dokažite identiteto in nato zgradite prvi CHILD SA
Druga izmenjava prenaša identiteto. S potrdili vsaka stran podpiše s svojim zasebnim ključem in predloži verigo, ki jo mora druga preveriti; z EAP odgovor izzove začetnika z izbrano metodo. Tu se končno pokažejo napačno ime strežnika, poteklo potrdilo ali zavrnjeno geslo.
Običajno IKE_AUTH pogaja tudi prvi CHILD SA, zato se zaščita podatkov dogovori v istem krogu. Začetnik predlaga izbirnike prometa, odgovor jih zoži ali zavrne, ključi podatkovne poti pa se izpeljejo iz IKE SA. To pomeni, da ena izmenjava lahko spodleti na dveh zelo različnih mestih: pri identiteti ali pri politiki. Berite obvestilo ali napako, ne splošne napake rokovanja, ker eno zdravi potrdilo, drugo pa neskladje podomrežja.
Dve SA, dve nalogi
| Združenje | Ščiti | Vedenje življenjske dobe |
|---|---|---|
| IKE SA | Krmilne izmenjave: obnavljanje ključev, brisanje, konfiguracijske obremenitve | Obnavlja se po lastnem urniku; podatkovna pot lahko spremembo preživi |
| CHILD SA | Promet aplikacije, ki ustreza izbirnikom prometa | Obnavlja se neodvisno, pogosto pogosteje |
Njuna ločitev pojasni dve vedenji, ki izgledata kot napaki. Tunel je lahko prikazan kot vzpostavljen, medtem ko v ozadju spodleti obnavljanje ključev, CHILD SA pa je mogoče zamenjati brez izgube povezave pri odjemalcu.
Pri strongSwamu referenca konfiguracije IKEv2 in swanctl --list-sas kažeta obe ravni, ip xfrm state skupaj z ip xfrm policy pa kažeta, kaj je jedro v resnici namestilo. Primerjava teh dveh pogledov je najhitrejša pot do tega, ali se je pogajanje končalo ali se je le zdelo končano. Če demonski proces navede CHILD SA, za katero jedro nima stanja, je namestitev tiho spodletela. Če ima jedro stanje, ki ga demonski proces ne pozna, gledate ostanek prejšnjega poskusa.
Kaj mora še veljati po dvigu tunela
Izbirniki prometa določajo, kateri naslovi so zajeti. Če odjemalec predlaga eno podomrežje, strežnik pa pričakuje drugo, CHILD SA se namesti, a ne prenaša nič koristnega, in napaka se pojavi kot težava usmerjanja, ne pogajanja. Nato mora lokalni sklad sodelovati: posredovanje omogočeno tam, kjer gostitelj usmerja, poti proti tunelu, pravila požarnega zidu, ki dovolijo dekapsulirane pakete, in notranji razreševalnik, če so vpletena zasebna imena. Vsak od teh spodleti posebej in nobenega ne popravi ponovni zagon demonskega procesa IKE.
Med diagnosticiranjem imejte dnevnik vidno: začetna izmenjava, nato preverjanje identitete, nato avtentikacija uporabnika, kjer velja, nato namestitev CHILD in nazadnje promet aplikacije. Korak, ki se ustavi, je tisti, ki ga je treba popraviti, in poznejša napaka usmerjanja nikoli ni razlog za popuščanje pri že opravljenih preverjanjih identitete.