Via IKEv2-SA estas aktiva sed mankas ida SA: legu la interŝanĝon

IKE diras ke la tunelo estas aktiva, ke la ida SA mankas, kaj ambaŭ asertoj povas esti veraj samtempe. Establita rega rilato ne estas datum-asocio, kaj la du objektoj havas apartajn vivdaŭrojn, intertraktadojn kaj malsukcesajn reĝimojn. Anonci la unuan kiel konektebleco estas la maniero per kiu bileto finiĝas per aserto ke la tunelo estas aktiva dum nenio funkcias. Legu la asocio-liston anstataŭ la resuma etikedo de la konekto, ĉar tiu listo estas la sola loko kie la mankanta objekto estas videbla. Sekvas la ordo en kiu la listo havas sencon.

Du asocioj, du taskoj

IKE-SA portas la regan kanalon: identojn, ŝlosilojn kaj la proponojn por la rega interŝanĝo mem. Ida SA portas la ESP-protekton, kun siaj propraj algoritmoj kaj siaj propraj trafik-selektiloj. Aŭtentikigo kaj ida kreado kutime iras kune, ĉar la unua ida SA estas intertraktata ene de IKE_AUTH, kaj ĝuste tiu kunligo surprizas homojn pri la apartigo.

Ĝi ankaŭ klarigas la du formojn de malsukceso kiujn vi renkontos. Ida SA rifuzita dum la komenca interŝanĝo kutime faligas ankaŭ la IKE-SA, do vi entute ne vidas establitan regan kanalon. IKE-SA staranta sola pli ofte signifas ke la unua ida SA sukcesis kaj ke posta provo krei idan SA malsukcesis, ekzemple dum ŝlosil-renovigo. Tempomarkoj apartigas tiujn kazojn pli rapide ol iu ajn konfigura-revizio.

Kiun tavolon rifuzis

Kiam ida SA estas rifuzita, la sciigo nomas la tavolon. Propona rifuzo signifas ke la partioj ne povis interkonsenti pri algoritmoj, ofte ĉar unu postulas alian grupon de perfekta antaŭa sekreteco aŭ ĉifron kiun la alia ne akceptos. Selektila rifuzo signifas ke la trafik-aro estis rifuzita rekte, kaj tio estas kovrada argumento, ne kriptografia.

Foje la manko de ida SA estas la dezajno. IKE-SA sen ida SA estas difinita etendo uzata tie kie la datum-asocio devas esti kreata laŭpeto, do la manko estas ĝusta kaj la ida SA aperas kiam alvenas kongrua trafiko. La notoj de strongSwan pri IKEv2 kovras kaj la laŭpetan stilon kaj la proponajn agordojn kiuj decidas la unuan kazon.

Kontrolu ĉu ekzistas laŭpeta aŭ kaptila konfiguro antaŭ ol diagnozi difekton. Se idaj SA estas kreataj mallrapide, manko de ida SA en ripozo estas la atendata stato, kaj la vera provo estas ĉu trafiko levigas unu. Tiu provo ankaŭ apartigas mallrapidan dezajnon de silentan malsukceson, ĉar malsukcesa kreado lasas la ekigilon senresponda anstataŭ nur en ripozo.

Poste demandu pri la datuma vojo

Post kiam ida SA ekzistas, la nombriloj respondas la sekvan demandon. ip -s xfrm state raportas pakaĵ- kaj bajt-kalkulojn por asocio, kaj ida SA kiu portas nenion dum vi generas trafikon indikas kongruon aŭ vojigon anstataŭ al mankanta asocio. swanctl --list-sas presas la selektilojn de la ida SA apud tiuj nombriloj, kaj tio konfirmas ke la pakaĵo sidas en la akceptita aro.

Tenadu aparte en la raporto la sukcesan aŭtentikigon kaj la malsukcesan idan interŝanĝon. Raporto kiu diras ke aŭtentikigo malsukcesis sendas la sekvan inĝenieron al la atestila stokejo, kaj la preciza frazo estas multe pli mallonga: la IKE-SA leviĝis, kaj la ida SA por ĉi tiu fluo neniam akceptiĝis.

Kunligu la du finojn

Por servilo kiun vi mem administras, prenu la protokolojn de kliento kaj pordego por la sama interŝanĝo anstataŭ kompari du rekonektajn provojn je unu horo distanco. La sciigoj devus kongrui ambaŭflanke, kaj kie ili ne kongruas, vi trovis la flankon kiu estas malĝuste agordita.

Korektu la idan intertraktadon, poste retestu kun trafiko ene de la celita selektilo. Tiu estas la sola provo kiu pruvas ke la mankanta objekto nun estas ĉeestanta, ĉar asocio-listo refreŝigita en ripozo povas aspekti idente antaŭ kaj post la korekto.