Kāpēc vietējā Windows IKEv2 vispār nav PSK lauka

Vārtejas dokumentācija saka, ka iepriekš kopīgā atslēga tiek ievadīta klientā, bet Windows profilā tam nav lauka. Šī plaisa nav kļūda, ko apiet, ierakstot atslēgu paroles laukā. Tā ir atšķirība starp to, ko protokols var, un to, ko piedāvā konkrēta realizācija.

Protokola iespēja nav klienta atbalsts

IKEv2 specifikācija ietver autentifikāciju ar kopīgu atslēgu, tāpēc vārteju tam var likumīgi konfigurēt. Vietējais Windows attālinātās piekļuves profils tā vietā dokumentē sertifikātu un EAP risinājumus, un protokola iespēja nerada lauku, parametru vai reģistra vērtību, kas klientam nekad nav bijusi.

Cilvēki parasti nonāk PowerShell atsauce VPN savienojuma pievienošanai, kur L2TP risinājumam parādīts L2tpPsk. Šis parametrs pieder L2TP un nav vispārējs IKEv2 noslēpums. Algoritmu izvēles iestatījumi izvēlas aizsardzības parametrus, kas ir trešā, nesaistītā lieta. Arī Windows Server maršrutēšanas loma nav tas pats objekts. Servera saskarnē var būt konfigurācijas vadīklas, kādu galddatora klienta profilā nav, un servera iestatījuma kopēšana darbstacijas profilā šo iespēju neatveido.

Izvēlieties sertifikātu, EAP vai L2TP

Ja vārtejas operators pieņems sertifikāta autentifikāciju, tas parasti ir vistīrākais galamērķis: klients uzrāda sertifikātu, vārteja to pārbauda pie uzticama izdevēja, un profilā nepaliek kopīgs noslēpums, ko kāds varētu nokopēt. Tam vajadzīga reģistrācija, uzticama ķēde un vārtejas konfigurācija, kas sertifikātu saista ar autorizācijas lēmumu.

EAP ar lietotāja akreditācijas datiem ir otrs atbalstītais ceļš šajā klientā, un tas pārceļ lēmumu pie identitātes nodrošinātāja. Tas arī ienes savas atkarības, jo EAP metodei, servera sertifikātam un klienta uzticēšanās šim sertifikātam visiem jāsakrīt. Pāreja uz L2TP/IPsec tikai pazīstama lauka dēļ maina protokolu steku. Tas ir pieņemami, ja tas ir atbalstīts lēmums ar dokumentētu iemeslu, un tas ir slikts iznākums, ja tas notiek tāpēc, ka kāds meklēja lauku atslēgas ierakstīšanai.

Pārbaudiet, ko pieņems vārteja

Pajautājiet operatoram, kādas autentifikācijas metodes attālinātās piekļuves pakalpojums piedāvā šodien, nevis kādas produkts atbalsta kopumā. Pakalpojums, kas konfigurēts IKEv2 tikai ar PSK, nepieņems sertifikātu tāpēc, ka klients to dod priekšroku.

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

Lasiet profila autentifikācijas metodi un sertifikātu krātuvi kopā. Profils, kas iestatīts uz EAP bez lietojama sertifikāta aiz tā, neizdodas tā, ka izskatās pēc servera problēmas.

Ja atbilde ir, ka pieejams tikai PSK, godīgās iespējas ir to atbalstošs apstiprināts klients vai vārtejas autentifikācijas dizaina maiņa. Neviens nav vietējs apiešanas risinājums, un pretējā apgalvošana rada savienojumu, ko var atkārtot tikai tas, kurš to konfigurējis.

Pierakstiet lēmumu un noslēpumus

Pierakstiet izvēlēto metodi, uzticības enkuru, tai atbilstošo identitāti un cilvēku, kurš apstiprināja izmaiņas. Šis ieraksts ir tas, kas vajadzīgs incidenta izskatīšanai, un tas arī neļauj nākamajam inženierim no jauna atklāt to pašu strupceļu.

Turiet noslēpumus atsevišķi savos pierakstos: konta parole, privātās atslēgas paroles frāze un vārtejas iepriekš kopīgā atslēga ir trīs dažādas lietas, pat ja iestatījumu ekrāns tās visas sauc par paroli. To sajaukšana ir ceļš, kā atslēga nonāk pieteikumā. Pārbaudiet iegūto profilu ar jaunu savienojumu un vienu lietojumprogrammas pieprasījumu uz privātu resursu. Veiksmīgs tunelis bez sasniedzama pakalpojuma ir daļējs rezultāts, un profilu nevajadzētu aprakstīt kā pabeigtu, kamēr arī resurss nedarbojas.