Documentația gateway-ului spune că cheia prepartajată se introduce în client, dar profilul Windows nu are niciun câmp pentru ea. Această lipsă nu este un defect ocolit scriind cheia în caseta de parolă. Este diferența dintre ce poate un protocol și ce oferă o anumită implementare.

Capacitatea protocolului nu este suportul clientului

Specificația IKEv2 include autentificarea cu cheie partajată, așa că un gateway poate fi configurat legitim pentru aceasta. Profilul nativ de acces la distanță din Windows documentează în schimb aranjamente cu certificate și EAP, iar capacitatea protocolului nu creează un câmp, un parametru sau o valoare de registru pe care clientul nu a avut-o niciodată.

Oamenii ajung de obicei la referință PowerShell pentru adăugarea unei conexiuni VPN, unde este afișat L2tpPsk pentru aranjamentul L2TP. Acel parametru aparține de L2TP și nu este un secret IKEv2 general. Setările de selecție a algoritmilor aleg parametri de protecție, ceea ce este un al treilea lucru fără legătură. Nici rolul de rutare din Windows Server nu este același obiect. O interfață de server poate avea controale de configurare pe care un profil de client desktop nu le are, iar copierea unei setări de server într-un profil de stație de lucru nu reproduce capacitatea.

Alegeți între certificat, EAP sau L2TP

Dacă operatorul gateway-ului acceptă autentificarea cu certificat, aceasta este de obicei destinația cea mai curată: clientul prezintă un certificat, gateway-ul îl validează la un emitent de încredere și niciun secret partajat nu rămâne într-un profil pentru ca cineva să îl copieze. Este nevoie de înrolare, un lanț de încredere și o configurație a gateway-ului care leagă certificatul de o decizie de autorizare.

EAP cu o acreditare de utilizator este cealaltă cale acceptată pe acest client și mută decizia către un furnizor de identitate. Aduce și propriile dependențe, deoarece metoda EAP, certificatul serverului și încrederea clientului în acel certificat trebuie să se alinieze. Trecerea la L2TP/IPsec doar pentru a obține un câmp familiar schimbă stiva de protocoale. Este acceptabil când este o alegere acceptată cu un motiv documentat și este un rezultat prost când se întâmplă pentru că cineva căuta o casetă în care să scrie o cheie.

Verificați ce va accepta gateway-ul

Întrebați operatorul ce metode de autentificare oferă astăzi serviciul de acces la distanță, nu pe care le acceptă produsul în general. Un serviciu configurat pentru IKEv2 doar cu PSK nu va accepta un certificat pentru că clientul preferă unul.

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

Citiți metoda de autentificare a profilului și magazinul de certificate împreună. Un profil setat pe EAP fără un certificat utilizabil în spate eșuează într-un mod care arată ca o problemă de server.

Dacă răspunsul este că este disponibil doar PSK, opțiunile sincere sunt un client aprobat care îl acceptă sau o schimbare în proiectarea autentificării gateway-ului. Niciuna nu este o soluție locală, iar a pretinde contrariul produce o conexiune pe care doar persoana care a configurat-o o poate reproduce.

Notați decizia și secretele

Notați metoda aleasă, ancora de încredere, identitatea care îi corespunde și persoana care a aprobat schimbarea. Acea înregistrare este ce are nevoie o analiză de incident și este și ce îl împiedică pe următorul inginer să redescopere aceeași fundătură.

Țineți secretele separate în notițe: o parolă de cont, o frază de acces pentru cheia privată și o cheie prepartajată a gateway-ului sunt trei lucruri diferite, chiar când un ecran de setări le numește pe toate parolă. Confundarea lor este modul în care o cheie ajunge într-un tichet. Testați profilul rezultat cu o conexiune nouă și o cerere de aplicație către o resursă privată. Un tunel reușit fără niciun serviciu accesibil este un rezultat parțial, iar profilul nu trebuie descris ca finalizat până când nici resursa nu funcționează.

Articole similare