Kial la denaska Windows IKEv2 tute ne havas kampon por PSK

La dokumentaro de la kluzo diras, ke la antaŭe dividita ŝlosilo eniriĝas en la klienton, sed la Windows-profino havas neniun kampon por ĝi. Tiu manko ne estas cimo, kiun oni ĉirkaŭiras tajpante la ŝlosilon en la pasvortan kampon. Ĝi estas la diferenco inter tio, kion protokolo povas, kaj tio, kion proponas difinita realigo.

Protokola kapablo ne estas klienta subteno

La specifo de IKEv2 inkluzivas aŭtentikigon per dividita ŝlosilo, do kluzo povas laŭleĝe esti agordita por ĝi. La denaska Windows-profino por malproksima aliro dokumentas anstataŭe atestilajn kaj EAP-aranĝojn, kaj protokola kapablo ne kreas kampon, parametron aŭ registran valoron, kiun la kliento neniam havis.

Homoj kutime finiĝas ĉe PowerShell-referenco por aldoni VPN-konekton, kaj tiu montras L2tpPsk por la L2TP-aranĝo. Tiu parametro apartenas al L2TP kaj ne estas ĝenerala IKEv2-sekreto. Agordoj por algoritma elekto elektas protektajn parametrojn, kio estas tria, nerilata afero. Ankaŭ la Windows Server-administra rolo ne estas la sama objekto. Servila interfaco povas havi agordajn regilojn, kiujn labortabla klienta profino ne havas, kaj kopii servilan agordon en stacian profinon ne reproduktas la kapablon.

Elektu inter atestilo, EAP aŭ L2TP

Se la kluzadministranto akceptos atestilan aŭtentikigon, tio kutime estas la plej pura celo: la kliento prezentas atestilon, la kluzo validigas ĝin ĉe fidinda eldoninto, kaj neniu dividita sekreto restas en profino por iu kopii. Ĝi postulas registriĝon, fidindan ĉenon kaj kluzan agordon, kiu ligas la atestilon al rajtiga decido.

EAP kun uzanta legitimilo estas la alia subtenata vojo en ĉi tiu kliento, kaj ĝi movas la decidon al identiga provizanto. Ĝi ankaŭ enkondukas proprajn dependecojn, ĉar la EAP-metodo, la servila atestilo kaj la fido de la kliento al tiu atestilo devas ĉiuj kongrui. Ŝanĝi al L2TP/IPsec nur por akiri konatan kampon ŝanĝas la protokolan stakon. Tio akcepteblas kiam ĝi estas subtenata elekto kun dokumentita kialo, kaj ĝi estas malbona rezulto kiam ĝi okazas ĉar iu serĉis skatolon por tajpi ŝlosilon.

Kontrolu, kion la kluzo akceptos

Demandu la administranton, kiujn aŭtentikigajn metodojn la malproksima alira servo proponas hodiaŭ, ne kiujn la produkto subtenas ĝenerale. Servo agordita por IKEv2 nur per PSK ne akceptos atestilon ĉar la kliento preferas unu.

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

Legu la aŭtentikigan metodon de la profino kaj la atestilan konservejon kune. Profino agordita al EAP sen uzebla atestilo malantaŭ ĝi malsukcesas tiel, ke ĝi aspektas kiel servila problemo.

Se la respondo estas, ke nur PSK disponeblas, la honestaj elektoj estas aprobita kliento, kiu subtenas ĝin, aŭ ŝanĝo de la aŭtentikiga desegno de la kluzo. Neniuna estas loka provizoraĵo, kaj ŝajnigi la malon produktas konekton, kiun nur la persono, kiu agordis ĝin, povas reprodukti.

Notu la decidon kaj la sekretojn

Notu la elektitan metodon, la fidfiksan punkton, la identecon ligitan al ĝi kaj la personon, kiu aprobis la ŝanĝon. Tiu noto estas tio, kion bezonas okaza revizio, kaj ĝi ankaŭ malhelpas la sekvan inĝenieron retrovi la saman sakstraton.

Tenu la sekretojn aparte en viaj notoj: konta pasvorto, pasfrazo de privata ŝlosilo kaj antaŭe dividita kluzoŝlosilo estas tri malsamaj aferoj, eĉ kiam agorda ekrano nomas ilin ĉiujn pasvorto. Ilia konfuzo estas la maniero, kiel ŝlosilo finiĝas en bileto. Testu la rezultan profinon per freŝa konekto kaj unu aplikada peto al privata rimedo. Sukcesa tunelo sen atingebla servo estas parta rezulto, kaj la profino ne estu priskribata kiel finita antaŭ ol ankaŭ la rimedo funkcias.