IKEv2 serveradresse vs identitet: kva klienten faktisk sjekkar

Ein gateway som endrar adresse kan halda fram med å fungera medan den same gatewayen bak eit nytt sertifikat stoppar, og det motsette skjer òg. Adressa fortel klienten der han skal senda pakkar; den autentiserte identiteten fortel klienten om kollegaen som svarer er den han skal stola på. IKEv2 beheld desse som to separate felt, noko som er nyttig når du sluttar å behandla dei som éin streng. Dei er også konfigurerte på ulike stader, slik at den eine kan vera rett medan den andre er feil.

Sjekk dei i denne rekkjefølgja og stopp ved den første mismatchen, fordi dei seinare sjekkane reknar med at dei tidlegare har bestått.

Først kva verdi er adressa

Tilkoplingsadressa er same kva klienten ringjer: ein IP, eit DNS namn som blir løyst til ein, eller eit belastningsbalansert grensesnitt. Det er transportinformasjon og ingenting meir. Identiteten rir i IKEv2 ID-nyttelasta og blir deretter matcha mot sertifikatet til kollegaen. Eit DNS namn i adresseboksen blir ikkje den forventa identiteten, og ein rå IP blir ikkje identiteten berre fordi kontakten er kopla til den.

I termar av strongSwan er adressa right eller left, og den forventa identiteten er rightid eller leftid, og det er det som IKEv2 konfigurasjonsdokumentasjonen beskriv. Om du berre nokon gong har redigert adressa, har du konfigurert halvparten av paret.

For det andre, kva sertifikatet kan bevisa

Identiteten har ein type, og sertifikatet må ha eit samsvarande namn. Ein DNS-identitet blir tilfredsstilt med ein dNSName-oppføring i emnealternativet namneutviding; ein Ip-identitet treng ein iPAddress-oppføring. Eit sertifikat ferda ut for vpn.example.com bevis ingenting om den bokstavelege adressa 203.0.113.10, og eit sertifikat ferda ut for den adressa beviser ingenting om namnet. Å gi nytt namn for eit anna namn er derfor ikkje ei drop-in-erstatning, sjølv når same nøkkel og CA blir gjenbrukt.

Moderne klientar ignorerer det vanlege namnet når det finst eit alternativt emnenamn, og mange ignorerer det fullstendig. Viss SAN-lista ikkje inneheld verdien som klienten sjekkar, mislykkast handtrykket etter at sertifikatet allereie er akseptert som påliteleg, og det er grunnen til at loggen blir lesen som ein identitetsfeil i staden for ein tillitsfeil.

For det tredje, korleis kvar klient oppgir forventningane

Windows tek servernamnet eller adressa du skreiv inn og krev at sertifikatet samsvarer med det, så å skriva inn ein IP skaper ei Ip-forventning. Android sin IKEv2 klient oppfører seg på same måte, og begge avviser eit gyldig, offentleg klarert sertifikat som namngir ein annan vert. En profil kan byrja å mislykkast berre fordi nokon erstatta vertsnamnet med adressa under ei migrering. Sjå på kva klienten bad om før du ser på kva sertifikatet inneheld.

På strongSwan er forventninga eksplisitt: sett rightid til identiteten serveren faktisk presenterer, som kan avvika frå høgre. Om du set han til %any aksepterer du kva kollegaen tilbyr og fjernar akkurat sjekken du prøver å behalda.

For det fjerde, skilje brukarinnlogging frå peer-identitet

EAP autentisering og serveridentiteten svarer på ulike spørsmål. Ein EAP identitet som [email protected] seier kven brukaren er, etter at klienten har bestemt at serveren er den rette. Rotering av passordet kan ikkje fiksa misforhold mellom peer-identitet, fordi tilkoplinga aldri når brukarinnloggingsstadiet.

Ein reinsa rapport bør namngi begge: identiteten klienten venta, identiteten serveren presenterte og sertifikatets SAN oppføringar.

For det femte, endre den gjennom ein stadfesta kanal

Når gatewayen lovleg flyttar seg, oppdater adressa først og la identiteten vera i fred, fordi det er tilfellet IKEv2 handterer godt. Når sjølve identiteten blir endra, behandla han som ei tillitshending og få den nye verdien frå ei kjelde du allereie stoler på, ikkje frå endepunktet som akkurat no sviktar. Ei melding levert over tilkoplinga du prøver å validera er ikkje bevis for den tilkoplinga.

Registrer den endelege adressa, identiteten og SAN-lista saman i profilnotata. Den neste personen som berører sertifikatet vil då sjå kven av dei tre som får flytta.