IKEv2 serveradresse vs identitet: hvad klienten faktisk tjekker

En gateway, der skifter adresse, kan blive ved med at fungere, mens den samme gateway bag et nyt certifikat stopper, og det omvendte sker også. Adressen fortæller klienten, hvor den skal sende pakker; den autentificerede identitet fortæller klienten, om den peer, der svarer, er den, den skal stole på. IKEv2 beholder dem som to separate felter, hvilket er nyttigt, når du stopper med at behandle dem som én streng. De er også konfigureret forskellige steder, så den ene kan være korrekt, mens den anden er forkert.

Tjek dem i denne rækkefølge og stop ved den første uoverensstemmelse, fordi de senere kontroller antager, at de tidligere er bestået.

Først hvilken værdi er adressen

Forbindelsesadressen er, hvad end klienten ringer til: en IP, et DNS navn, der løses til en, eller en belastningsbalanceret frontend. Det er transportinformation og intet mere. Identiteten kører i IKEv2 ID-nyttelasten og matches derefter mod peers certifikat. Et DNS navn i adressefeltet bliver ikke den forventede identitet, og en rå IP bliver ikke til identiteten, bare fordi stikket er tilsluttet det.

I strongSwan termer er adressen right eller left, og den forventede identitet er rightid eller leftid, og det er, hvad IKEv2 konfigurationsdokumentationen beskriver. Hvis du kun har redigeret adressen, har du konfigureret halvdelen af parret.

For det andet, hvad certifikatet kan bevise

Identiteten har en type, og certifikatet skal bære et matchende navn. En DNS identitet er opfyldt af en dNSName indtastning i emnets alternative navneudvidelse; en IP-identitet kræver en iPAddress-indgang. Et certifikat udstedt for vpn.example.com beviser intet om den bogstavelige adresse 203.0.113.10, og et certifikat udstedt for denne adresse beviser intet om navnet. Genudgivelse for et andet navn er derfor ikke en drop-in-erstatning, selv når den samme nøgle og CA genbruges.

Moderne kunder ignorerer det almindelige navn, når der findes et alternativt emnenavn, og mange ignorerer det fuldstændigt. Hvis SAN-listen ikke indeholder den værdi, som klienten kontrollerer, mislykkes håndtrykket, efter at certifikatet allerede er blevet accepteret som troværdigt, hvorfor loggen læses som en identitetsfejl snarere end en tillidsfejl.

For det tredje, hvordan hver klient angiver forventningen

Windows tager det servernavn eller den adresse, du har indtastet, og kræver, at certifikatet matcher det, så indtastning af en IP skaber en IP-forventning. Androids IKEv2-klient opfører sig på samme måde, og begge afviser et gyldigt, offentligt betroet certifikat, der navngiver en anden vært. En profil kan begynde at fejle, blot fordi nogen erstattede værtsnavnet med dets adresse under en migrering. Se på, hvad klienten bad om, før du ser på, hvad certifikatet indeholder.

På strongSwan er forventningen eksplicit: sæt rightid til den identitet serveren faktisk præsenterer, som kan afvige fra højre. Hvis du indstiller den til %any accepteres det, som peeren tilbyder, og fjerner præcis den check, du forsøger at beholde.

For det fjerde, adskil brugerlogin fra peer-identitet

EAP-godkendelse og serveridentiteten besvarer forskellige spørgsmål. En EAP identitet såsom [email protected] siger, hvem brugeren er, efter at klienten har besluttet, at serveren er den rigtige. Rotation af denne adgangskode kan ikke rette en peer-identitetsmismatch, fordi forbindelsen aldrig når bruger-login-stadiet.

En desinficeret rapport skal navngive både: den identitet, klienten forventede, den identitet, serveren præsenterede, og certifikatets SAN-poster.

For det femte, skift det gennem en verificeret kanal

Når gatewayen lovligt flytter sig, skal du først opdatere adressen og lade identiteten være i fred, for det er tilfældet IKEv2 håndterer godt. Når selve identiteten ændres, skal du behandle den som en tillidshændelse og få den nye værdi fra en kilde, du allerede har tillid til, ikke fra det endepunkt, der i øjeblikket fejler. En besked leveret via den forbindelse, du forsøger at validere, er ikke bevis for den forbindelse.

Notér den endelige adresse, identitet og SAN liste sammen i profilnoterne. Den næste person, der rører ved certifikatet, vil så se, hvem af de tre, der får lov til at flytte.