IKEv2 servila adreso vs identeco: kion la kliento efektive kontrolas

Enirejo kiu ŝanĝas adreson povas daŭre funkcii dum la sama enirejo malantaŭ nova atestilo ĉesas, kaj ankaŭ okazas la inverso. La adreso diras al la kliento kie sendi pakaĵojn; la aŭtentikigita identeco rakontas al la kliento ĉu la kunulo respondanta estas tiu kiun ĝi devus fidi. IKEv2 konservas tiujn kiel du apartajn kampojn, kio estas utila post kiam vi ĉesas trakti ilin kiel unu ĉenon. Ili ankaŭ estas agorditaj en malsamaj lokoj, do unu povas esti ĝusta dum la alia estas malĝusta.

Kontrolu ilin en ĉi tiu ordo kaj ĉesu ĉe la unua miskongruo, ĉar la postaj kontroloj supozas ke la pli fruaj pasis.

Unue, kiu valoro estas la adreso

La konektadreso estas kia ajn la kliento diskas: IP, DNS nomo kiu solvas al unu, aŭ ŝarĝo-ekvilibra antaŭa finaĵo. Tio estas transportaj informoj kaj nenio pli. La identeco veturas en la IKEv2 ID-utila ŝarĝo kaj tiam estas kongrua kun la atestilo de la kunulo. DNS nomo en la adreskesto ne fariĝas la atendata identeco, kaj kruda IP ne fariĝas la identeco nur ĉar la ingo konektita al ĝi.

En strongSwan terminoj, la adreso estas right aŭ left, kaj la atendata identeco estas rightid aŭ leftid, kaj tion priskribas la IKEv2 agorda dokumentaro. Se vi nur iam redaktis la adreson, vi agordis duonon de la paro.

Due, kion la atestilo povas pruvi

La identeco havas tipon, kaj la atestilo devas porti kongruan nomon. DNS identeco estas kontentigita per dNSName enskribo en la subjekta alternativa nom-etendaĵo; IP-identeco bezonas iPAddress enskribon. Atestilo eldonita por vpn.example.com pruvas nenion pri la laŭvorta adreso 203.0.113.10, kaj unu eldonita por tiu adreso pruvas nenion pri la nomo. Reeldonado por malsama nomo do ne estas aldona anstataŭaĵo, eĉ kiam la sama klavo kaj CA estas reuzataj.

Modernaj klientoj ignoras la komunan nomon kiam subjekta alternativa nomo ekzistas, kaj multaj ignoras ĝin tute. Se la SAN listo ne enhavas la valoron kiun la kliento kontrolas, la manpremo malsukcesas post kiam la atestilo jam estis akceptita kiel fidinda, tial la protokolo legas kiel identeraro prefere ol fidinda eraro.

Trie, kiel ĉiu kliento deklaras la atendon

Windows prenas la servilnomon aŭ adreson kiun vi tajpis kaj postulas ke la atestilo kongruu kun ĝi, do tajpi IP kreas IP-atendon. La IKEv2-kliento de Android kondutas same, kaj ambaŭ malakceptas validan, publike fidindan atestilon kiu nomas malsaman gastiganton. Profilo povas komenci malsukcesi nur ĉar iu anstataŭigis la gastigan nomon per ĝia adreso dum migrado. Rigardu, kion la kliento petis antaŭ ol vi rigardas, kion enhavas la atestilo.

Je strongSwan la atendo estas eksplicita: agordu rightid al la identeco, kiun la servilo efektive prezentas, kiu povas malsami de dekstre. Agordi ĝin al %any akceptas ĉion, kion la samulo proponas kaj forigas ĝuste la ĉekon, kiun vi provas konservi.

Kvare, aparta uzantsaluto de kunula identeco

EAP aŭtentigo kaj la servila identeco respondas malsamajn demandojn. EAP identeco kiel [email protected] diras kiu estas la uzanto, post kiam la kliento decidis ke la servilo estas la ĝusta. Rotaci tiun pasvorton ne povas ripari kunulan identecmalkongruon, ĉar la konekto neniam atingas la uzant-ensaluta stadion.

Sanigita raporto devus nomi ambaŭ: la identecon, kiun la kliento atendis, la identecon, kiun la servilo prezentis, kaj la SAN enskribojn de la atestilo.

Kvine, ŝanĝu ĝin per kontrolita kanalo

Kiam la enirejo laŭleĝe moviĝas, ĝisdatigu la adreson unue kaj lasu la identecon, ĉar tiel IKEv2 bone traktas. Kiam la identeco mem ŝanĝiĝas, traktu ĝin kiel fidan eventon kaj ricevu la novan valoron de fonto, kiun vi jam fidas, ne de la finpunkto, kiu nuntempe malsukcesas. Mesaĝo transdonita per la konekto, kiun vi provas validigi, ne estas pruvo pri tiu konekto.

Registradu la finan adreson, identecon kaj SAN liston kune en la profilnotoj. La sekva persono, kiu tuŝos la atestilon, tiam vidos, kiu el la tri rajtas moviĝi.