IKEv2 serveradresse vs identitet: hva klienten faktisk sjekker

En gateway som endrer adresse kan fortsette å fungere mens den samme gatewayen bak et nytt sertifikat stopper, og det motsatte skjer også. Adressen forteller klienten hvor den skal sende pakker; den autentiserte identiteten forteller klienten om kollegaen som svarer er den den skal stole på. IKEv2 beholder disse som to separate felt, noe som er nyttig når du slutter å behandle dem som én streng. De er også konfigurert på forskjellige steder, slik at den ene kan være riktig mens den andre er feil.

Sjekk dem i denne rekkefølgen og stopp ved den første mismatchen, fordi de senere sjekkene antar at de tidligere har bestått.

Først hvilken verdi er adressen

Tilkoblingsadressen er uansett hva klienten ringer: en IP, et DNS navn som løses til en, eller et belastningsbalansert grensesnitt. Det er transportinformasjon og ingenting mer. Identiteten rir i IKEv2 ID-nyttelasten og blir deretter matchet mot kollegaens sertifikat. Et DNS navn i adresseboksen blir ikke den forventede identiteten, og en rå IP blir ikke identiteten bare fordi kontakten er koblet til den.

I termer av strongSwan er adressen right eller left, og den forventede identiteten er rightid eller leftid, og det er det som IKEv2 konfigurasjonsdokumentasjonen beskriver. Hvis du bare noen gang har redigert adressen, har du konfigurert halvparten av paret.

For det andre, hva sertifikatet kan bevise

Identiteten har en type, og sertifikatet må ha et samsvarende navn. En DNS-identitet tilfredsstilles med en dNSName-oppføring i emnealternativet navneutvidelse; en IP-identitet trenger en iPAddress-oppføring. Et sertifikat utstedt for vpn.example.com beviser ingenting om den bokstavelige adressen 203.0.113.10, og et sertifikat utstedt for den adressen beviser ingenting om navnet. Å gi nytt navn for et annet navn er derfor ikke en drop-in-erstatning, selv når samme nøkkel og CA gjenbrukes.

Moderne klienter ignorerer det vanlige navnet når det finnes et alternativt emnenavn, og mange ignorerer det fullstendig. Hvis SAN-listen ikke inneholder verdien som klienten sjekker, mislykkes håndtrykket etter at sertifikatet allerede er akseptert som pålitelig, og det er grunnen til at loggen leses som en identitetsfeil i stedet for en tillitsfeil.

For det tredje, hvordan hver klient oppgir forventningene

Windows tar servernavnet eller adressen du skrev inn og krever at sertifikatet samsvarer med det, så å skrive inn en IP skaper en IP-forventning. Android sin IKEv2 klient oppfører seg på samme måte, og begge avviser et gyldig, offentlig klarert sertifikat som navngir en annen vert. En profil kan begynne å mislykkes bare fordi noen erstattet vertsnavnet med adressen under en migrering. Se på hva klienten ba om før du ser på hva sertifikatet inneholder.

På strongSwan er forventningen eksplisitt: sett rightid til identiteten serveren faktisk presenterer, som kan avvike fra høyre. Hvis du setter den til %any aksepterer du hva kollegaen tilbyr og fjerner akkurat sjekken du prøver å beholde.

For det fjerde, skille brukerinnlogging fra peer-identitet

EAP autentisering og serveridentiteten svarer på forskjellige spørsmål. En EAP identitet som [email protected] sier hvem brukeren er, etter at klienten har bestemt at serveren er den rette. Rotering av passordet kan ikke fikse uoverensstemmelser mellom peer-identitet, fordi tilkoblingen aldri når brukerinnloggingsstadiet.

En renset rapport bør navngi begge: identiteten klienten forventet, identiteten serveren presenterte og sertifikatets SAN oppføringer.

For det femte, endre den gjennom en bekreftet kanal

Når gatewayen lovlig flytter seg, oppdater adressen først og la identiteten være i fred, fordi det er tilfellet IKEv2 håndterer godt. Når selve identiteten endres, behandle den som en tillitshendelse og få den nye verdien fra en kilde du allerede stoler på, ikke fra endepunktet som for øyeblikket svikter. En melding levert over tilkoblingen du prøver å validere er ikke bevis for den tilkoblingen.

Registrer den endelige adressen, identiteten og SAN-listen sammen i profilnotatene. Den neste personen som berører sertifikatet vil da se hvem av de tre som får flytte.