네이티브 Windows IKEv2에 PSK 필드가 전혀 없는 이유

게이트웨이 문서에는 미리 공유한 키를 클라이언트에 넣는다고 되어 있지만, Windows 프로필에는 그 필드가 없습니다. 이 간극은 암호 상자에 키를 입력해서 우회할 버그가 아닙니다. 프로토콜이 할 수 있는 일과 특정 구현이 제공하는 것의 차이입니다.

프로토콜의 능력은 클라이언트 지원이 아닙니다

IKEv2 명세에는 공유 키 인증이 포함되어 있으므로 게이트웨이를 그것에 맞게 구성하는 것은 정당합니다. 반면 네이티브 Windows 원격 액세스 프로필은 인증서와 EAP 방식을 문서화하며, 프로토콜의 능력이 클라이언트에 한 번도 없었던 필드나 매개 변수, 레지스트리 값을 만들어 내지는 않습니다.

사람들은 보통 VPN 연결을 추가하는 PowerShell 참조에 도달하고, 거기에는 L2TP 방식용 L2tpPsk가 표시됩니다. 이 매개 변수는 L2TP에 속하며 일반적인 IKEv2 비밀이 아닙니다. 알고리즘 선택 설정은 보호 매개 변수를 고르는 것으로, 세 번째이자 무관한 이야기입니다. Windows Server의 라우팅 역할도 같은 개체가 아닙니다. 서버 인터페이스에는 데스크톱 클라이언트 프로필에 없는 구성 제어가 있을 수 있고, 서버 설정을 워크스테이션 프로필로 복사해도 그 능력이 재현되지 않습니다.

인증서, EAP 또는 L2TP 중에서 고르십시오

게이트웨이 운영자가 인증서 인증을 받아들인다면 보통 그것이 가장 깔끔한 목적지이며, 클라이언트가 인증서를 제시하고, 게이트웨이가 신뢰할 수 있는 발급자에 대해 검증하며, 누군가 복사할 공유 비밀이 프로필에 남지 않습니다. 등록, 신뢰 체인, 인증서를 권한 부여 결정에 연결하는 게이트웨이 구성이 필요합니다.

사용자 자격 증명을 쓰는 EAP는 이 클라이언트에서 지원되는 다른 경로이며 결정을 ID 공급자로 옮깁니다. EAP 방식, 서버 인증서, 그 인증서에 대한 클라이언트의 신뢰가 모두 맞아야 하므로 자체 종속성도 가져옵니다. 익숙한 필드를 얻으려고 L2TP/IPsec으로 바꾸면 프로토콜 스택이 바뀝니다. 문서화된 이유가 있는 지원되는 선택이라면 받아들일 수 있지만, 누군가 키를 입력할 칸을 찾고 있었기 때문에 일어난 일이라면 나쁜 결과입니다.

게이트웨이가 무엇을 받아들일지 확인하십시오

운영자에게는 제품이 일반적으로 지원하는 방식이 아니라 원격 액세스 서비스가 오늘 제공하는 인증 방식을 물으십시오. PSK 전용으로 구성된 IKEv2 서비스는 클라이언트가 인증서를 선호한다는 이유로 인증서를 받아들이지 않습니다.

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

프로필의 인증 방식과 인증서 저장소를 함께 읽으십시오. 뒤에 쓸 만한 인증서가 없는 EAP 설정 프로필은 서버 문제처럼 보이는 방식으로 실패합니다.

답이 PSK만 가능하다면 정직한 선택은 그것을 지원하는 승인된 클라이언트나 게이트웨이의 인증 설계 변경입니다. 어느 쪽도 임시방편이 아니며, 그렇지 않은 척하면 구성한 사람만 재현할 수 있는 연결이 생깁니다.

결정과 비밀을 기록하십시오

선택한 방식, 신뢰 닻, 그에 대응하는 ID, 변경을 승인한 사람을 적어 두십시오. 그 기록이 사고 검토에 필요한 것이며, 다음 엔지니어가 같은 막다른 길을 다시 발견하지 못하게 하는 것이기도 합니다.

메모에서 설정 화면이 모두를 비밀번호라고 불러도 계정 비밀번호, 개인 키 암호 문구, 게이트웨이의 미리 공유한 키를 세 가지 다른 것으로 분리해 두십시오. 이것을 혼동하는 것이 키가 티켓에 남는 경로입니다. 결과 프로필을 새 연결과 개인 리소스에 대한 응용 프로그램 요청 하나로 시험하십시오. 접근 가능한 서비스 없이 터널만 성공한 것은 부분적인 결과이며, 리소스도 동작할 때까지 프로필을 완료라고 부르면 안 됩니다.