Bakit walang PSK field ang native na Windows IKEv2

Sinasabi ng dokumentasyon ng gateway na ang paunang ibinahaging key ay inilalagay sa client, ngunit walang field ang Windows profile para dito. Ang puwang na ito ay hindi bug na iniiwasan sa pag-type ng key sa kahon ng password. Ito ang pagkakaiba ng kayang gawin ng isang protocol at ng iniaalok ng isang partikular na implementasyon.

Ang kakayahan ng protocol ay hindi suporta ng client

Kasama sa IKEv2 specification ang authentication na may shared key, kaya lehitimong maaaring i-configure ang gateway para dito. Ang native na Windows remote access profile ay nagdodokumento sa halip ng mga kaayusan sa certificate at EAP, at ang kakayahan ng protocol ay hindi lumilikha ng field, parameter o registry value na hindi kailanman nagkaroon ang client.

Karaniwang napupunta ang mga tao sa reference ng PowerShell para sa pagdaragdag ng koneksyon sa VPN, at doon ipinapakita ang L2tpPsk para sa L2TP na kaayusan. Ang parameter na iyon ay kabilang sa L2TP at hindi pangkalahatang sikreto ng IKEv2. Pinipili ng mga setting ng pagpili ng algorithm ang mga parameter ng proteksyon, na ikatlo at walang kaugnayang bagay. Hindi rin parehong object ang routing role ng Windows Server. Maaaring may mga configuration control ang server interface na wala sa desktop client profile, at ang pagkopya ng setting ng server sa workstation profile ay hindi muling gumagawa ng kakayahang iyon.

Pumili sa pagitan ng certificate, EAP o L2TP

Kung tatanggapin ng operator ng gateway ang certificate authentication, iyon ang karaniwang pinakamalinis na patutunguhan: nagpapakita ang client ng certificate, bine-beripika ito ng gateway sa isang pinagkakatiwalaang issuer, at walang shared secret na natitira sa profile para kopyahin ng sinuman. Nangangailangan ito ng enrollment, pinagkakatiwalaang chain at gateway configuration na nag-uugnay sa certificate sa desisyon sa awtorisasyon.

Ang EAP na may user credential ay ang isa pang sinusuportahang landas sa client na ito, at inililipat nito ang desisyon sa identity provider. Nagdadala rin ito ng sarili nitong dependencies, dahil ang EAP method, server certificate at tiwala ng client sa certificate na iyon ay dapat magtugma lahat. Ang paglipat sa L2TP/IPsec para lamang makakuha ng pamilyar na field ay nagbabago ng protocol stack. Katanggap-tanggap iyon kapag ito ay sinusuportahang pagpipilian na may dokumentadong dahilan, at masamang resulta kapag nangyari ito dahil may naghahanap ng kahon kung saan magta-type ng key.

Tingnan kung ano ang tatanggapin ng gateway

Tanungin ang operator kung anong mga paraan ng authentication ang iniaalok ng remote access service ngayon, hindi kung alin ang sinusuportahan ng produkto sa pangkalahatan. Ang serbisyong naka-configure para sa IKEv2 na PSK lamang ay hindi tatanggap ng certificate dahil mas gusto ito ng client.

Get-VpnConnection -Name "Corp IKEv2" | Format-List AuthenticationMethod, TunnelType, EncryptionLevel, ServerValidation
Get-ChildItem Cert:\CurrentUser\My | Select-Object Subject, NotAfter

Basahin nang sabay ang authentication method ng profile at ang certificate store. Ang profile na nakatakda sa EAP na walang magagamit na certificate sa likod ay nabibigo sa paraang mukhang problema ng server.

Kung ang sagot ay PSK lamang ang available, ang tapat na mga opsyon ay isang aprubadong client na sumusuporta dito o pagbabago sa disenyo ng authentication ng gateway. Wala sa dalawa ang lokal na solusyon, at ang pagpapanggap na kabaligtaran ay gumagawa ng koneksyon na tanging ang nag-configure nito ang makagagawa muli.

Itala ang desisyon at ang mga sikreto

Itala ang napiling paraan, ang trust anchor, ang identity na tumutugma dito at ang taong nag-apruba ng pagbabago. Ang rekord na iyon ang kailangan ng incident review, at ito rin ang pumipigil sa susunod na engineer na muling matuklasan ang parehong dead end.

Panatilihing hiwalay ang mga sikreto sa iyong mga tala: ang password ng account, passphrase ng private key at paunang ibinahaging key ng gateway ay tatlong magkakaibang bagay, kahit tinatawag ng settings screen ang lahat na password. Ang paghahalo sa kanila ang paraan kung paano napupunta ang key sa ticket. Subukan ang resultang profile sa bagong koneksyon at isang application request sa isang pribadong resource. Ang matagumpay na tunnel na walang maabot na serbisyo ay bahagyang resulta, at hindi dapat ilarawan ang profile bilang tapos hangga't hindi rin gumagana ang resource.