VPN сертификат на Mac-у: који налог види пролаз?

Профил приказује ваше име, видљива ознака сертификата говори нешто друго, а дневник пролаза бележи трећи идентификатор. Ниједан од њих не лаже, и управо је то проблем: три различита поља читају се као да одговарају на једно питање. Веза представља акредитив, IKEv2 идентификатор и налог, а пролаз одлучује који од њих шта овлашћује.

Три идентитета у једној вези

Видљиво име профила је ознака за људе. Оно бира везу и ништа друго. Сертификат је акредитив, а да ли може нешто да докаже зависи од тога да ли клијент има одговарајући приватни кључ. Поље налога је тврдња о главном субјекту, а сервер га сме мапирати на други локални идентитет.

Када провера идентитета не успе, питајте на које се од три поља грешка односи. Одбијен акредитив, непознат идентификатор и онемогућен налог дају различите поруке, а третирање свега као једног «проблема са сертификатом» води вас у погрешну конзолу.

Читајте изворна поља према њиховој намени

У управљаној изворној IKEv2 конфигурацији Apple-ова референца корисног терета раздваја вредности, а метода провере идентитета одређује која је комбинација потребна:

Сертификат и EAP пријава могу имати различите улоге у истој вези. Не присиљавајте свако поље да држи исти текст само зато што једно од њих то чини, и не претпостављајте да промена једног поништава остала. VPN апликација треће стране може приказати потпуно другачији модел; користите њен документовани избор идентитета уместо да преносите изворна имена поља у њу.

Сертификат сервера није идентитет клијента

Сертификат који проверава пролаз је сидро поверења. Доказује да сте стигли на сервер који сте очекивали. Идентитет клијента је други објекат: укључује приступ приватном кључу који доказује да је страна која се повезује она за коју се представља. Преименовање видљивог налога не може једно да претвори у друго.

Ту добронамерна исправка крене наопако. Увоз пролазовог CA сертификата у складиште клијента не чини ништа за проверу идентитета клијента, а означавање тог уноса корисничким именом не чини га корисничким идентитетом. Два објекта живе у различитим деловима профила и одговарају на различита питања.

Пратите главни субјекат до мапирања на пролазу

Потврдите за шта је акредитив издат: за овог корисника, овај уређај или заједничку улогу. Mac налог за пријаву није аутоматски тај главни субјекат, а сертификат копиран са другог рачунара задржава идентитет рачунара за који је издат.

Затим упоредите стварни акредитив, а не ознаку. Издавалац, серијски број и отисак прста омогућавају вама и администратору да потврдите да говорите о истом објекту. Приказана имена се могу мењати и често дуплирају, што их чини најгорим могућим идентификатором током инцидента.

Последњи корак је на пролазу. Замолите његовог власника да повеже једну везу са представљеним идентификаторима и са правилом мапирања налога које их је потрошило. Ознака на страни клијента не може утврдити шта је сервер одлучио, а правило које мапира сертификат на онемогућен налог неће успети док сва поља на страни клијента изгледају исправно.

Поправите слој који поседује неслагање

Ако профил показује на погрешан акредитив, исправите његову референцу или избор. Ако акредитив припада другом главном субјекту, прођите кроз поновну регистрацију код издаваоца уместо да уређујете ознаке. Ако пролаз везује важећи акредитив за погрешан налог, његов власник политике мора исправити мапирање. То су три различите промене са три различита одобраваоца.

Обнова заслужује исту пажњу. Замена сертификата, преименовање његове видљиве ознаке и премештање особе између система налога не утичу нужно на мапирање на исти начин. Забележите коју сте од три ствари променили, јер ће следећи неуспех изгледати исто са стране клијента, а другачије у дневнику пролаза.

Делите само минималне јавне идентификаторе који су потребни подршци. Приватни кључ или цео пакет идентитета никада није део те размене, колико год то олакшало дијагнозу.