VPN сертификат за Mac: кой акаунт вижда шлюзът?

Профилът показва вашето име, видимият етикет на сертификата казва нещо друго, а журналът на шлюза записва трети идентификатор. Никое от тях не лъже и точно това е проблемът: три различни полета се четат така, сякаш отговарят на един въпрос. Връзката представя удостоверение, идентификатор по IKEv2 и акаунт, а шлюзът решава кое от тях за какво дава право.

Три самоличности в една връзка

Видимото име на профила е етикет за хора. То избира връзка и нищо друго. Сертификатът е удостоверение и дали може да докаже нещо, зависи от това дали клиентът държи съответния частен ключ. Полето за акаунт е твърдение за принципал, а сървърът е свободен да го съпостави с различна локална самоличност.

Когато удостоверяването се провали, питайте кой от трите е засегнат от грешката. Отхвърлено удостоверение, неизвестен идентификатор и деактивиран акаунт дават различни съобщения, а третирането им като един «проблем със сертификата» ви изпраща в грешната конзола.

Четете собствените полета според тяхната задача

В управлявана собствена конфигурация по IKEv2 референцията за полезен товар на Apple разделя стойностите, а методът за удостоверяване решава коя комбинация е необходима:

Сертификат и вход през EAP могат да имат различни роли в една и съща връзка. Не принуждавайте всяко поле да съдържа един и същ текст само защото едно от тях го прави, и не предполагайте, че промяната на едно отменя останалите. VPN приложение на трета страна може да показва напълно различен модел; използвайте документирания там избор на самоличност, вместо да пренасяте собствени имена на полета.

Сертификатът на сървъра не е самоличност на клиента

Сертификатът, който валидира шлюза, е котва на доверие. Той доказва, че сте стигнали до сървъра, който очаквате. Самоличността на клиента е различен обект: тя включва достъп до частния ключ, който доказва, че свързващата се страна е тази, за която се представя. Преименуването на видим акаунт не може да превърне едното в другото.

Тук добронамерената поправка се обърква. Импортирането на CA сертификата на шлюза в хранилището на клиента не прави нищо за удостоверяването на клиента, а етикетирането на този запис с името на потребителя не го прави потребителска самоличност. Двата обекта живеят в различни части на профила и отговарят на различни въпроси.

Проследете принципала до съпоставянето в шлюза

Потвърдете за какво е издадено удостоверението: за този потребител, за това устройство или за споделена роля. Акаунтът за вход в Mac не е автоматично този принципал, а сертификат, копиран от друга машина, запазва самоличността на машината, за която е издаден.

След това сравнете самото удостоверение, а не етикета. Издател, сериен номер и отпечатък позволяват на вас и на администратора да потвърдите, че обсъждате един и същ обект. Показваните имена са редактируеми и често се дублират, което ги прави най-лошият възможен идентификатор по време на инцидент.

Последната стъпка е в шлюза. Помолете неговия собственик да свърже една връзка с представените идентификатори и с правилото за съпоставяне на акаунти, което ги е консумирало. Етикет от страна на клиента не може да установи какво е решил сървърът, а правило, което съпоставя сертификат с деактивиран акаунт, ще се проваля, докато всички полета от страна на клиента изглеждат правилни.

Поправете слоя, който притежава несъответствието

Ако профилът сочи към грешно удостоверение, коригирайте референцията или избора му. Ако удостоверението принадлежи на друг принципал, минете през повторното записване при издателя, вместо да редактирате етикети. Ако шлюзът свързва валидно удостоверение с грешен акаунт, собственикът на политиката му трябва да поправи съпоставянето. Това са три различни промени с трима различни одобряващи.

Подновяването заслужава същото внимание. Смяната на сертификата, преименуването на видимия му етикет и преместването на човек между системи за акаунти не влияят непременно на съпоставянето по един и същ начин. Записвайте кое от трите сте променили, защото следващият отказ ще изглежда еднакво от страна на клиента и различно в журнала на шлюза.

Споделяйте само минималните публични идентификатори, които поддръжката има нужда. Частен ключ или пълен пакет за самоличност никога не е част от тази размяна, колкото и удобна да би била диагностиката.