Mac VPN-atestilo: kiun konton vidas la pordego?

La profilo montras vian nomon, la videbla etikedo de la atestilo diras ion alian, kaj la protokolo de la pordego registras trian identigilon. Neniu el ili mensogas, kaj ĝuste tio estas la problemo: tri malsamaj kampoj estas legitaj kvazaŭ ili respondus al unu demando. La konekto prezentas legitimilon, IKEv2-identigilon kaj konton, kaj la pordego decidas, kiu el ili rajtigas kion.

Tri identecoj en unu konekto

La videbla profila nomo estas etikedo por homoj. Ĝi elektas konekton kaj nenion pli. La atestilo estas legitimilo, kaj ĉu ĝi povas pruvi ion ajn dependas de tio, ĉu la kliento posedas la kongruan privatan ŝlosilon. La konto-kampo estas aserto pri ĉefa identeco, kaj la servilo rajtas mapi ĝin al alia loka identeco.

Kiam aŭtentigo malsukcesas, demandu, al kiu el la tri la eraro rilatas. Rifuzita legitimilo, nekonata identigilo kaj malŝaltita konto produktas malsamajn mesaĝojn, kaj trakti ilin kiel unu «atestilan problemon» sendas vin al la malĝusta konzolo.

Legu la denaskajn kampojn laŭ ilia tasko

En administrata denaska IKEv2-agordo, la utilŝarĝa referenco de Apple apartigas la valorojn, kaj la aŭtentiga metodo decidas, kiu kombinaĵo necesas:

Atestilo kaj EAP-ensaluto povas havi apartajn rolojn en la sama konekto. Ne devigu ĉiun kampon teni la saman tekston nur ĉar unu el ili faras tion, kaj ne supozu, ke ŝanĝo de unu superregas la aliajn. Triaparta VPN-aplikaĵo povas montri tute alian modelon; uzu ĝian dokumentitan identec-elekton anstataŭ porti denaskajn kamponomojn en ĝin.

Servila atestilo ne estas klienta identeco

La atestilo, kiu validigas la pordegon, estas fida ankro. Ĝi pruvas, ke vi atingis la servilon, kiun vi atendis. Klienta identeco estas alia objekto: ĝi inkluzivas aliron al la privata ŝlosilo, kiu pruvas, ke la konektiĝanta parto estas tiu, kiu ĝi asertas esti. Renomado de videbla konto ne povas ŝanĝi unu en la alian.

Ĉi tie bonintenca ripeto misfunkcias. Importi la CA-atestilon de la pordego en la klientan konservejon faras nenion por klienta aŭtentigo, kaj etikedi tiun enskribon per la uzantnomo ne igas ĝin uzanta identeco. La du objektoj loĝas en malsamaj partoj de la profilo kaj respondas al malsamaj demandoj.

Sekvu la ĉefan identecon ĝis la pordega mapado

Konfirmu, por kio la legitimilo estis eldonita: por ĉi tiu uzanto, ĉi tiu aparato aŭ komuna rolo. La Mac-ensaluta konto ne aŭtomate estas tiu ĉefa identeco, kaj atestilo kopiita de alia maŝino konservas la identecon de la maŝino, por kiu ĝi estis eldonita.

Poste komparu la faktan legitimilon, ne la etikedon. Eldoninto, seria numero kaj fingrospuro ebligas al vi kaj al la administranto konfirmi, ke vi diskutas la saman objekton. Montrataj nomoj estas redakteblaj kaj ofte duobligataj, kio igas ilin la plej malbona ebla identigilo dum incidento.

La lasta paŝo estas ĉe la pordego. Petu ĝian posedanton kunigi unu konekton kun la prezentitaj identigiloj kaj kun la kontomapa regulo, kiu konsumis ilin. Klientflanka etikedo ne povas establi, kion la servilo decidis, kaj regulo, kiu mapas atestilon al malŝaltita konto, malsukcesos dum ĉiu klientflanka kampo aspektas ĝusta.

Riparu la tavolon, kiu posedas la miskongruon

Se la profilo montras la malĝustan legitimilon, korektu ĝian referencon aŭ elekton. Se la legitimilo apartenas al alia ĉefa identeco, trapasu la rean registriĝon ĉe la eldoninto anstataŭ redakti etikedojn. Se la pordego ligas validan legitimilon al la malĝusta konto, ĝia politika posedanto devas ripari la mapadon. Temas pri tri malsamaj ŝanĝoj kun tri malsamaj aprobantoj.

Renovigo meritas la saman zorgon. Anstataŭigi la atestilon, renomi ĝian videblan etikedon kaj transloki personon inter kontaj sistemoj ne nepre efikas al la mapado sammaniere. Notu, kiun el la tri vi ŝanĝis, ĉar la sekva malsukceso aspektos idente de la klienta flanko kaj alie en la pordega protokolo.

Kunhavigu nur la minimumajn publikajn identigilojn, kiujn subteno bezonas. Privata ŝlosilo aŭ kompleta identeca pako neniam estas parto de tiu interŝanĝo, kiom ajn oportune ĝi farus la diagnozon.