Ang IKEv2 ay hindi isang handshake: IKE SA, authentication, pagkatapos CHILD SA

Maaaring isipin mong ang koneksyon ng IKEv2 ay isang palitan na nagtatapos sa naka-encrypt na trapiko. Dalawa ito kahit papaano, at ang una ay hindi nagpapatunay ng sinuman. Nagsisimula ang mga kapares sa mga control message, nagkakasundo sa cryptographic na parameter, nagpapatunay ng pagkakakilanlan, at saka lamang nakikipag-usap sa estado na nagdadala ng mga pakete ng aplikasyon. Ang pagkakasunod-sunod na iyon ang nagpapaliwanag sa pagkakasalungat na laging inirereport: sumasagot ang gateway, sinasabi ng kliyente na konektado, ngunit nag-timeout pa rin ang pribadong aplikasyon. Narito ang ginagawa ng bawat yugto at kung ano ang dapat totoo pagkatapos nito.

Ang mito: kapag sumagot ang gateway, konektado ka

Ang sagot sa unang mensahe ay nagpapatunay na maabot ang endpoint at handa itong makipag-usap. Hindi nito pinapatunayan na tinanggap ang account, na na-validate ang chain ng sertipiko, o na may na-install na patakaran sa datos.

Nangyayari ang mga kabiguan na iyon mamaya, at iba ang sintomas. Dumarating ang pagtanggi ng sertipiko o pagkabigo ng EAP pagkatapos nang magtagumpay ang unang palitan, kaya napakaliit ng sinasabi ng ping sa UDP 500 at berdeng icon sa kliyente.

IKE_SA_INIT: magkasundo sa parameter, hindi sa pagkakakilanlan

Ang unang palitan ay nagdadala ng mga panukala para sa IKE security association: mga algorithm sa encryption at integridad, isang pseudorandom na function, at isang Diffie-Hellman group. Nagpapalitan din ang mga kapares ng nonce, at hinango ng bawat panig ang key material para sa IKE SA mula sa shared secret na nililikha ng mga value na iyon. Walang anuman sa palitang ito ang nagtatakda kung sino ang kabilang panig. Itinatakda lamang nito na makalkula ng dalawang panig ang parehong mga key at nagkakasundo sila sa isang panukala. Ang responder na walang gusto sa alinmang panukala ay tumatanggi sa palitan dito, kaya mukhang patay ang server kapag may mismatch sa bersyon o algorithm.

Ang IKE SA na nalikha sa puntong ito ay nagpoprotekta sa lahat ng susunod na palitan sa pamamahala. Iyon ang trabaho nito, at ibang trabaho iyon kaysa sa pagprotekta sa iyong mga pakete.

IKE_AUTH: patunayan ang pagkakakilanlan, pagkatapos buuin ang unang CHILD SA

Ang ikalawang palitan ay nagdadala ng pagkakakilanlan. Sa mga sertipiko, pumipirma ang bawat kapares gamit ang sariling pribadong key at naghahain ng chain na dapat i-validate ng isa; sa EAP, hinahamon ng responder ang initiator sa napiling paraan. Dito lumilitaw sa wakas ang maling pangalan ng server, nag-expire na sertipiko o tinanggihang password.

Karaniwang kinakausap din ng IKE_AUTH ang unang CHILD SA, kaya napagkasunduan ang proteksyon ng datos sa parehong paglalakbay. Nagmumungkahi ang initiator ng traffic selector, hinihigpitan o tinatanggihan ng responder, at ang mga key ng data path ay hinango mula sa IKE SA. Ibig sabihin, ang isang palitan ay maaaring mabigo sa dalawang magkaibang lugar: pagkakakilanlan o patakaran. Basahin ang notification payload o error sa halip na ang pangkalahatang handshake failure, dahil sertipiko ang lunas sa isa at subnet mismatch ang sa isa pa.

Dalawang SA, dalawang trabaho

Ang paghihiwalay sa kanila ay nagpapaliwanag ng dalawang pag-uugali na parang bug. Maaaring magpakita ang tunnel na naka-set up habang nabibigo ang pag-renew ng key sa background, at mapapalitan ang CHILD SA nang hindi nawawala ang koneksyon ng kliyente.

Sa strongSwan, ang reference ng configuration ng IKEv2 at swanctl --list-sas ay nagpapakita ng dalawang antas, at ip xfrm state kasama ng ip xfrm policy ay nagpapakita kung ano talaga ang in-install ng kernel. Ang paghahambing ng dalawang tanawin iyon ang pinakamabilis na paraan upang makita kung natapos ang negosasyon o mukha lamang natapos. Kung naglista ang daemon ng CHILD SA na walang estado sa kernel, tahimik na nabigo ang pag-install. Kung may hawak na estado ang kernel na hindi alam ng daemon, tinitingnan mo ang natira mula sa naunang pagtatangka.

Ano pa ang dapat totoo kapag nakataas na ang tunnel

Tinutukoy ng traffic selector kung aling address ang sakop. Kung isang subnet ang iminumungkahi ng kliyente at iba ang inaasahan ng server, naka-install ang CHILD SA pero wala itong dalang kapaki-pakinabang, at lumilitaw ang error bilang problema sa routing at hindi sa negosasyon. Pagkatapos, kailangang makipagtulungan ang lokal na stack: naka-enable ang forwarding sa lugar na nagru-route ang host, mga ruta patungo sa tunnel, mga patakaran ng firewall na pumapayag sa decapsulated na pakete, at panloob na resolver kung may pribadong pangalan. Bawat isa sa mga iyon ay hiwalay na nabigo at wala sa mga ito ang naaayos sa pamamagitan ng pag-restart ng IKE daemon.

Panatilihing nakikita ang log habang nag-diagnose: ang unang palitan, pagkatapos ang validation ng pagkakakilanlan, pagkatapos ang authentication ng user kung applicable, pagkatapos ang pag-install ng CHILD, at sa huli ang trapiko ng aplikasyon. Ang yugtong humihinto ang dapat ayusin, at ang mamaya pang pagkabigo sa routing ay hindi kailanman dahilan para luwagan ang mga pagsusuri sa pagkakakilanlan na nakapasa na.