Profilen visar ditt namn, certifikatets synliga etikett säger något annat och gatewayens logg registrerar en tredje identifierare. Ingen av dem ljuger, och det är just problemet: tre olika fält läses som om de svarade på en enda fråga. Anslutningen presenterar en autentiseringsuppgift, en IKEv2-identifierare och ett konto, och gatewayen avgör vilken av dem som auktoriserar vad.

Tre identiteter i en anslutning

Det synliga profilnamnet är en etikett för människor. Det väljer en anslutning och ingenting annat. Certifikatet är en autentiseringsuppgift, och om det kan bevisa något beror på om klienten har den matchande privata nyckeln. Kontofältet är ett påstående om en principal, och servern får fritt mappa det till en annan lokal identitet.

När autentiseringen misslyckas, fråga vilken av de tre felet avser. Avvisade autentiseringsuppgifter, en okänd identifierare och ett inaktiverat konto ger olika meddelanden, och att behandla dem som ett enda «certifikatproblem» skickar dig till fel konsol.

Läs de inbyggda fälten efter deras uppgift

I en hanterad inbyggd IKEv2-konfiguration skiljer Apples nyttolastreferens värdena, och autentiseringsmetoden avgör vilken kombination som krävs:

FieldIdentifiesCommon misreading
AuthNameUsername for the configured arrangementAssuming it is the certificate subject
LocalIdentifierIKEv2 client identifierAssuming it must equal the username
PayloadCertificateUUIDReferenced credential payloadAssuming any installed certificate will do

Ett certifikat och en EAP-inloggning kan ha olika roller i samma anslutning. Tvinga inte varje fält att innehålla samma text bara för att ett av dem gör det, och anta inte att en ändring åsidosätter de andra. En VPN-app från tredje part kan visa en helt annan modell; använd dess dokumenterade identitetsval i stället för att föra in inbyggda fältnamn i den.

Ett servercertifikat är inte en klientidentitet

Certifikatet som validerar gatewayen är ett förtroendeankare. Det bevisar att du nådde den server du förväntade dig. En klientidentitet är ett annat objekt: den omfattar åtkomst till den privata nyckeln som bevisar att parten som ansluter är den den utger sig för att vara. Att byta namn på ett synligt konto kan inte göra det ena till det andra.

Det är här en välmenande rättelse går fel. Att importera gatewayens CA-certifikat till klientarkivet gör ingenting för klientautentiseringen, och att märka den posten med användarens namn gör den inte till en användaridentitet. De två objekten lever i olika delar av profilen och svarar på olika frågor.

Följ principalen till gatewayens mappning

Bekräfta vad autentiseringsuppgiften utfärdades för: den här användaren, den här enheten eller en delad roll. Mac-inloggningskontot är inte automatiskt den principalen, och ett certifikat som kopierats från en annan maskin behåller identiteten för den maskin det utfärdades för.

Jämför sedan själva autentiseringsuppgiften, inte etiketten. Utfärdare, serienummer och fingeravtryck låter dig och administratören bekräfta att ni talar om samma objekt. Visade namn kan redigeras och dupliceras ofta, vilket gör dem till den sämsta tänkbara identifieraren under en incident.

Det sista steget är på gatewayen. Be dess ägare korrelera en anslutning med de presenterade identifierarna och med den kontomappningsregel som förbrukade dem. En etikett på klientsidan kan inte fastställa vad servern beslutade, och en regel som mappar ett certifikat till ett inaktiverat konto kommer att misslyckas medan alla fält på klientsidan ser korrekta ut.

Reparera det lager som äger avvikelsen

Om profilen pekar på fel autentiseringsuppgift, rätta referensen eller valet. Om autentiseringsuppgiften tillhör en annan principal, gå igenom utfärdarens nyregistrering i stället för att redigera etiketter. Om gatewayen binder giltiga autentiseringsuppgifter till fel konto måste dess policyägare rätta mappningen. Det är tre olika ändringar med tre olika godkännare.

Förnyelse förtjänar samma omsorg. Att byta certifikatet, byta namn på dess synliga etikett och flytta en person mellan kontosystem påverkar inte nödvändigtvis mappningen på samma sätt. Anteckna vilken av de tre du ändrade, eftersom nästa fel kommer att se identiskt ut från klienten och annorlunda ut i gatewayens logg.

Dela bara de minimala offentliga identifierare som supporten behöver. En privat nyckel eller ett komplett identitetspaket är aldrig en del av det utbytet, hur praktiskt det än skulle göra diagnostiken.

Relaterade artiklar