IKEv2 ne estas unu manpremo: unue IKE SA, poste identeca kontrolo, poste CHILD SA
Respondo de la enirejo pruvas atingeblon, ne identecon. Sekvu IKE_SA_INIT, IKE_AUTH kaj la unuan CHILD SA, poste kontrolu kio devas esti vera antaŭ ol trafiko fluas.
Vi eble pensas, ke IKEv2-konekto estas unu interŝanĝo, kiu finiĝas per ĉifrado de via trafiko. Fakte estas almenaŭ du, kaj la unua ne aŭtentikigas iun ajn. La partneroj komencas per kontrolaj mesaĝoj, interkonsentas pri kriptografiaj parametroj, pruvas identecon kaj nur poste intertraktas la staton, kiu portas aplikajn pakaĵojn. Tiu ordo klarigas la malkongruon, kiun homoj konstante raportas: la enirejo respondas, la kliento diras ke ĝi konektiĝis, kaj la privata aplikaĵo ankoraŭ finiĝas per tempolimo. Jen kion ĉiu etapo efektive faras, kaj kio devas esti vera post ĝi.
La mito: se la enirejo respondas, vi estas konektita
Respondo al la unua mesaĝo pruvas, ke la finpunkto estas atingebla kaj pretas paroli. Ĝi ne pruvas, ke konto estis akceptita, ke certifikada ĉeno validiĝis, aŭ ke iu ajn datuma politiko estis instalita.
Tiuj fiaskoj okazas poste, kaj ili produktas malsamajn simptomojn. Certifikada rifuzo aŭ EAP-fiasko alvenas post kiam la unua interŝanĝo jam sukcesis, kaj tial ping al UDP 500 kaj verda klienta ikono diras tiel malmulte.
IKE_SA_INIT: interkonsenti pri parametroj, ne pri identeco
La unua interŝanĝo portas proponojn por la IKE-sekureca asocio: ĉifradaj kaj integrecaj algoritmoj, pseŭdohazarda funkcio kaj Diffie-Hellman-grupo. La partneroj ankaŭ interŝanĝas nonce, kaj ĉiu flanko derivas ŝlosilan materialon por la IKE SA el la komuna sekreto, kiun tiuj valoroj produktas. Nenio en ĉi tiu interŝanĝo establas, kiu estas la alia partio. Ĝi establas, ke ambaŭ flankoj povas komputi la samajn ŝlosilojn kaj ke ili konsentas pri propono. Respondanto, kiu ŝatas neniun proponon, rifuzas la interŝanĝon ĉi tie, kaj tial versia aŭ algoritma malkongruo aspektas kiel malfunkcia servilo.
La IKE SA kreita ĉe ĉi tiu punkto protektas ĉiujn postajn administrajn interŝanĝojn. Tio estas ĝia tasko, kaj ĝi estas malsama tasko ol protekti viajn pakaĵojn.
IKE_AUTH: pruvu identecon, poste konstruu la unuan CHILD SA
La dua interŝanĝo portas identecon. Kun certifikadoj, ĉiu partnero subskribas per sia privata ŝlosilo kaj prezentas ĉenon, kiun la alia devas validigi; kun EAP, la respondanto defias la iniciatinton per la elektita metodo. Ĉi tie fine aperas malĝusta servila nomo, eksvalidiĝinta certifikado aŭ rifuzita pasvorto.
En la normala kazo IKE_AUTH ankaŭ intertraktas la unuan CHILD SA, do la datuma protekto interkonsentiĝas en la sama vojaĝo. La iniciatinto proponas trafikajn selektilojn, la respondanto mallarĝigas aŭ rifuzas ilin, kaj ŝlosiloj por la datuma vojo estas derivitaj el la IKE SA. Tio signifas, ke unu interŝanĝo povas fiaski en du tre malsamaj lokoj: identeco aŭ politiko. Legu la notify-ŝarĝon aŭ la eraron anstataŭ la ĝenerala manprema fiasko, ĉar la riparo por unu estas certifikado kaj por la alia subnet-malkongruo.
Du SA-oj, du taskoj
| Association | Protects | Lifetime behaviour |
|---|---|---|
| IKE SA | Management exchanges: rekeying, delete, configuration payloads | Rekeyed on its own schedule; the data path can survive the change |
| CHILD SA | Application traffic matching the traffic selectors | Rekeyed independently, often more frequently |
Teni ilin aparte klarigas du kondutojn, kiuj aspektas kiel cimoj. Tunelo povas montriĝi establita dum ŝlosila renovigo fiaskas en la fono, kaj CHILD SA povas esti anstataŭigita sen ke la kliento perdas la konekton.
En strongSwan, la IKEv2-agorda referenco kaj swanctl --list-sas montras ambaŭ nivelojn, kaj ip xfrm state plus ip xfrm policy montras, kion la kerno efektive instalas. Kompari tiujn du vidpunktojn estas la plej rapida maniero vidi, ĉu la intertraktado finiĝis aŭ nur aspektis finita. Se la demono listigas CHILD SA, por kiu la kerno havas neniun staton, la instalado fiaskis silente. Se la kerno tenas staton, kiun la demono ne konas, vi rigardas restaĵon de pli frua provo.
Kio ankoraŭ devas esti vera post kiam la tunelo funkcias
Trafikaj selektiloj difinas, kiuj adresoj estas kovritaj. Se la kliento proponas unu subreton kaj la servilo atendas alian, la CHILD SA instaliĝas sed portas nenion utilan, kaj la eraro aperas kiel enkursiga problemo anstataŭ intertraktada problemo. Poste la loka stako devas kunlabori: plusendo ŝaltita tie, kie la gastiganto enkursigas, itineroj al la tunelo, fajroŝirmaj reguloj permesantaj la malenkapsuligitajn pakaĵojn, kaj interna solvilo se privataj nomoj estas engaĝitaj. Ĉiu el tiuj fiaskas aparte kaj neniu estas riparita per restartigo de la IKE-demono.
Tenu la protokolon videbla dum vi diagnozas: la komenca interŝanĝo, poste identeca validigo, poste uzanta aŭtentikigo kie ĝi aplikiĝas, poste CHILD-instalado, poste aplika trafiko. La etapo, kiu haltas, estas la etapo riparinda, kaj posta enkursiga fiasko neniam estas kialo malstreĉi la identecajn kontrolojn, kiuj jam pasis.