Sertipiko ng VPN sa Mac: aling account ang nakikita ng gateway?

Ipinapakita ng profile ang iyong pangalan, iba ang sinasabi ng nakikitang label ng sertipiko, at nagtatala ang log ng gateway ng ikatlong identifier. Wala sa kanila ang nagsisinungaling, at iyon mismo ang problema: tatlong magkakaibang field ang binabasa na parang sumasagot sa isang tanong. Naghahain ang koneksyon ng kredensyal, identifier ng IKEv2 at account, at ang gateway ang nagpapasya kung alin sa kanila ang nagpapahintulot sa ano.

Tatlong pagkakakilanlan sa isang koneksyon

Ang nakikitang pangalan ng profile ay label para sa mga tao. Pumipili ito ng koneksyon at wala nang iba. Ang sertipiko ay kredensyal, at kung makapagpapatunay ito ng anuman ay nakadepende sa kung hawak ng kliyente ang tugmang pribadong susi. Ang field ng account ay pahayag tungkol sa isang principal, at malaya ang server na i-map ito sa ibang lokal na pagkakakilanlan.

Kapag nabigo ang pagpapatotoo, itanong kung alin sa tatlo ang tinutukoy ng error. Ang tinanggihang kredensyal, hindi kilalang identifier at naka-disable na account ay gumagawa ng magkakaibang mensahe, at ang pagtrato sa kanila bilang isang «problema sa sertipiko» ay nagpapadala sa iyo sa maling console.

Basahin ang mga native na field ayon sa kanilang tungkulin

Sa pinamamahalaang native na IKEv2 configuration, hinihiwalay ng payload reference ng Apple ang mga halaga, at ang paraan ng pagpapatotoo ang nagpapasya kung aling kombinasyon ang kailangan:

Ang sertipiko at EAP login ay maaaring may magkaibang tungkulin sa parehong koneksyon. Huwag pilitin ang bawat field na maglaman ng parehong teksto dahil lang ginagawa ito ng isa sa kanila, at huwag ipagpalagay na ang pagbabago ng isa ay nagsasawalang-bisa sa iba. Maaaring magpakita ng ganap na ibang modelo ang VPN app ng third party; gamitin ang dokumentadong pagpili ng pagkakakilanlan nito sa halip na dalhin ang mga native na pangalan ng field doon.

Ang sertipiko ng server ay hindi pagkakakilanlan ng kliyente

Ang sertipikong nagpapatunay sa gateway ay angkla ng tiwala. Pinapatunayan nito na naabot mo ang server na inaasahan mo. Ang pagkakakilanlan ng kliyente ay ibang bagay: kasama ang pag-access sa pribadong susi na nagpapatunay na ang kumokonektang panig ay siya ang sinasabi niyang siya. Hindi mababago ng pagpapalit ng pangalan ng nakikitang account ang isa patungo sa isa pa.

Dito nagkakamali ang isang may mabuting layuning pagwawasto. Ang pag-import ng CA certificate ng gateway sa client store ay walang ginagawa para sa pagpapatotoo ng kliyente, at ang paglalagay ng pangalan ng user sa entry na iyon ay hindi ito ginagawang pagkakakilanlan ng user. Ang dalawang bagay ay naninirahan sa magkaibang bahagi ng profile at sumasagot sa magkakaibang tanong.

Sundan ang principal hanggang sa mapping ng gateway

Tiyakin kung para saan inilabas ang kredensyal: para sa user na ito, sa device na ito o sa shared na tungkulin. Ang login account ng Mac ay hindi awtomatikong ang principal na iyon, at ang sertipikong kinopya mula sa ibang makina ay pinananatili ang pagkakakilanlan ng makinang inilabasan nito.

Pagkatapos ay ihambing ang aktwal na kredensyal, hindi ang label. Ang issuer, serial number at fingerprint ay nagpapahintulot sa iyo at sa administrator na kumpirmahin na pinag-uusapan ninyo ang parehong bagay. Ang mga ipinapakitang pangalan ay nae-edit at madalas madoble, kaya sila ang pinakamasamang posibleng identifier sa panahon ng insidente.

Ang huling hakbang ay nasa gateway. Hilingin sa may-ari nito na iugnay ang isang koneksyon sa mga inihandang identifier at sa tuntunin ng account mapping na gumamit sa kanila. Hindi matutukoy ng label sa panig ng kliyente ang nagpasya ang server, at ang tuntuning nagma-map ng sertipiko sa naka-disable na account ay mabibigo habang ang lahat ng field sa panig ng kliyente ay mukhang tama.

Ayusin ang layer na nagmamay-ari ng hindi pagkakatugma

Kung ang profile ay tumuturo sa maling kredensyal, itama ang reference o ang pagpili. Kung ang kredensyal ay pag-aari ng ibang principal, dumaan sa muling pagpaparehistro sa issuer sa halip na i-edit ang mga label. Kung ang gateway ay nag-uugnay ng valid na kredensyal sa maling account, dapat itama ng may-ari ng patakaran ang mapping. Iyon ay tatlong magkakaibang pagbabago na may tatlong magkakaibang tagapag-apruba.

Ang pag-renew ay karapat-dapat sa parehong pag-iingat. Ang pagpapalit ng sertipiko, pagpapalit ng pangalan ng nakikitang label nito at paglipat ng isang tao sa pagitan ng mga account system ay hindi laging nakakaapekto sa mapping sa parehong paraan. Itala kung alin sa tatlo ang binago mo, dahil ang susunod na pagkasira ay magmumukhang pareho mula sa kliyente at iba sa log ng gateway.

Ibahagi lamang ang pinakamababang pampublikong identifier na kailangan ng suporta. Ang pribadong susi o kumpletong identity bundle ay hindi kailanman bahagi ng pagpapalitang iyon, gaano man kaginhawa para sa diagnosis.