IKEv2-atestilo kaj SAN: kial la identeca kontrolo malsukcesas

Via atestilo ĉenas al fidinda CA, la datoj estas en ordo, kaj la samtavolano tamen rifuzas fini fazon 1 kun identeca eraro. Atingebleco kaj valida subskribo estas nur duono de tio, kion kontrolas IKEv2-kliento. La alia duono estas ĉu la identeco, kiun ĝi atendas, aperas en la atestilo en la ĝusta kampo, kaj tiun atendo difinas la profilo, ne la dosiernomo de la atestilo.

La simptomo ĉiam havas la saman formon

Konekta profilo ŝanĝiĝas de gastigantnomo al IP-adreso, aŭ renoviĝas de atestilo kun DNS-nomo al tiu, kiu portas nur adresojn, kaj la tunelo ĉesas negocadi. Nenio sur la reta vojo ŝanĝiĝis. La kliento atingas la samtavolanon, ricevas atestilon kaj rifuzas la identecon de la samtavolano ĉar la identigilo, kiun ĝi estis dirita atendi, ne estas reprezentita en kampo, kiun ĝi akceptas. Renovigoj estas la kutima kaŭzo, ĉar la anstataŭa atestilo ofte venas el alia ŝablono ol tiu, kiun ĝi anstataŭas.

Ambaŭ flankoj tiam registras ion senutilan, kaj tial la malsukceso kutime raportiĝas kiel atestila problemo. La klienta protokolo eble nomas la identecon, kiun ĝi volis, kaj tiu nomo estas la indico, kiun vi bezonas, ne la findato.

Kongruigu la tipon de la identigilo, ne nur la valoron

dNSName-SAN kaj iPAddress-SAN estas malsamaj kampoj kun malsamaj kongruaj reguloj, do atestilo, kiu portas 203.0.113.10 kiel DNS-ĉenon, ne kontentigas klienton, kiu atendas IP-identecon. Modernaj validigiloj grandparte ignoras la komunan nomon, do la amika etikedo en la atestilaj detaloj pruvas nenion pri tio, kio kongruos. Se gastigantnomo estis anstataŭigita per adreso dum problemtraktado, supozu, ke la atendata identeco moviĝis kun ĝi, ĝis vi kontrolis. Komparu la ĉenon en la profilo kun la ĉeno en la SAN signon post signo, ĉar fina punkto aŭ superflua spaco sufiĉas.

Ĵokeroj estas oportuneco nur por DNS kaj sekvas proprajn kongruajn regulojn, kio estas plia kialo, kial IP-bazita profilo neniam fidu al ili.

Trovu, kie ĉiu kliento konservas la atendo

En strongSwan la valoro komparata kun la atestilo venas el la agordo de samtavolana identeco: rightid en la klasika agordo, aŭ la id de fora konekta sekcio en swanctl. La dokumentaro pri Apple IKEv2-interfunkciado utilas ĉi tie, ĉar ĝi klarigas la identecajn konvenciojn, kiujn uzas profilgvidata kliento, kaj tiuj konvencioj klarigas klason de miskongruo, kiu ŝajnas hazarda sur la reto.

Apple-agordaj profiloj portas kampon de fora identigilo, kaj la valoro tie estas tio, kion la kliento kontrolas, ne la servila adreso en la konektaj agordoj. Windows kaj aparataj klientoj havas ĉiu sian propran kampon kun sia propra defaŭlto, kaj la defaŭlto ofte sekvas la adreson, kiun vi tajpis. Kiam du kampoj malkongruas, venkas tiu, kiun la kliento efektive legas, kaj ĝi malofte estas tiu, kiun vi redaktis.

Riparu la profilon aŭ la atestilon intence

Inspektu la atestilon de la samtavolano per aprobitaj iloj kaj listigu la SAN-erojn kun iliaj tipoj antaŭ ol ŝanĝi ion. Tiu inspekto bezonas nek privatan ŝlosilon nek alŝuton, kaj ĝi solvas la demandon en sekundoj. Se la disfaldiĝo celas unu DNS-identecon, la atestilo devas porti ĝin kiel dNSName-eron, kaj se ĝi celas adreson, la atestilo bezonas iPAddress-eron por ĝuste tiu adreso.

Kiam la atestilo estas malĝusta, petu korektitan de la operatoro kun la specifa atendata identigilo. Kiam la profilo estas malĝusta, riparu la profilon kaj lasu la atestilon trankvila. Malŝalti identecan validigon igas la eraron malaperi kaj forigas la kontrolon, ke la tunelo parolas kun la samtavolano, kiun vi intencis.

Dokumentu la atendatan identecon por ĉiu klienta platformo, ĉar valoro, kiun unu kliento derivas aŭtomate, eble devas esti eksplicita en alia.

Donu al la renoviga peto kvar faktojn

Notu la atendatan identigilon kaj ĝian tipon, la SAN-erojn, kiujn la nuna atestilo efektive havas, la klienton kaj version, kiuj faras la kontrolon, kaj la precizan erartekston. Renoviga peto konstruita el tiuj kvar linioj ricevas la ĝustan atestilon unuafoje, anstataŭ alian kun la sama konata dosiernomo.