IKEv2 serveradres versus identiteit: wat de client feitelijk controleert

Een gateway die van adres verandert, kan blijven werken terwijl dezelfde gateway achter een nieuw certificaat stopt, en het omgekeerde gebeurt ook. Het adres vertelt de client waar pakketten naartoe moeten worden gestuurd; de geauthenticeerde identiteit vertelt de cliënt of de peer-antwoording degene is die hij moet vertrouwen. IKEv2 bewaart deze als twee afzonderlijke velden, wat handig is als u ze niet meer als één string behandelt. Ze zijn ook op verschillende plaatsen geconfigureerd, dus de een kan gelijk hebben en de ander ongelijk.

Controleer ze in deze volgorde en stop bij de eerste mismatch, omdat bij latere controles wordt aangenomen dat de eerdere zijn geslaagd.

Ten eerste, welke waarde is het adres

Het verbindingsadres is wat de client ook kiest: een IP-adres, een DNS-naam die wordt omgezet in één, of een front-end met evenwichtige taakverdeling. Dat is transportinformatie en niets meer. De identiteit zit in de ID-payload IKEv2 en wordt vervolgens vergeleken met het certificaat van de peer. Een DNS-naam in het adresvak wordt niet de verwachte identiteit, en een onbewerkt IP-adres wordt niet de identiteit alleen maar omdat de socket erop is aangesloten.

In strongSwan-termen is het adres right of left, en de verwachte identiteit is rightid of leftid, en dat is wat de IKEv2 configuratiedocumentatie beschrijft. Als u het adres alleen maar heeft bewerkt, heeft u de helft van het paar geconfigureerd.

Ten tweede, wat het certificaat kan bewijzen

De identiteit heeft een type en het certificaat moet een overeenkomende naam dragen. Aan een DNS-identiteit wordt voldaan door een dNSName-vermelding in de alternatieve naamextensie van het onderwerp; een IP-identiteit heeft een iPAddress-invoer nodig. Een certificaat uitgegeven voor vpn.example.com bewijst niets over het letterlijke adres 203.0.113.10, en een certificaat uitgegeven voor dat adres bewijst niets over de naam. Het opnieuw uitgeven onder een andere naam is dus geen drop-in vervanging, zelfs niet als dezelfde sleutel en CA opnieuw worden gebruikt.

Moderne klanten negeren de algemene naam als er een alternatieve naam voor het onderwerp bestaat, en velen negeren deze volledig. Als de SAN-lijst niet de waarde bevat die de client controleert, mislukt de handshake nadat het certificaat al als betrouwbaar is geaccepteerd, Daarom leest het log eerder als een identiteitsfout dan als een vertrouwensfout.

Ten derde, hoe elke klant de verwachting uitdrukt

Windows neemt de servernaam of het adres dat u hebt getypt en vereist dat het certificaat daarmee overeenkomt, dus het typen van een IP creëert een IP-verwachting. De IKEv2-client van Android gedraagt zich op dezelfde manier en beide wijzen een geldig, publiek vertrouwd certificaat af dat een andere host noemt. Een profiel kan mislukken alleen maar omdat iemand tijdens een migratie de hostnaam heeft vervangen door het bijbehorende adres. Kijk eerst waar de klant om vroeg voordat je kijkt wat er in het certificaat staat.

Op strongSwan is de verwachting expliciet: stel rightid in op de identiteit die de server daadwerkelijk presenteert, die kan afwijken van rechts. Als u dit instelt op %any, accepteert u alles wat de peer aanbiedt en verwijdert u precies de cheque die u probeert te behouden.

Ten vierde: scheid de gebruikersaanmelding van de peer-identiteit

EAP-authenticatie en de serveridentiteit beantwoorden verschillende vragen. Een EAP identiteit zoals [email protected] zegt wie de gebruiker is, nadat de client heeft besloten dat de server de juiste is. Het roteren van dat wachtwoord kan een niet-overeenkomende peer-identiteit niet oplossen, omdat de verbinding nooit de fase van inloggen van de gebruiker bereikt.

Een opgeschoond rapport moet beide benoemen: de identiteit die de client verwachtte, de identiteit die de server presenteerde, en de SAN-vermeldingen van het certificaat.

Ten vijfde: verander het via een geverifieerd kanaal

Wanneer de gateway legitiem beweegt, update dan eerst het adres en laat de identiteit met rust, want dat is het geval IKEv2 kan goed omgaan. Wanneer de identiteit zelf verandert, behandel deze dan als een vertrouwensgebeurtenis en haal de nieuwe waarde op van een bron die u al vertrouwt, niet van het eindpunt dat momenteel faalt. Een bericht dat wordt afgeleverd via de verbinding die u probeert te valideren, is geen bewijs voor die verbinding.

Noteer het uiteindelijke adres, de identiteit en de SAN-lijst samen in de profielnotities. De volgende die het certificaat aanraakt, ziet dan wie van de drie mag bewegen.