SSTP와 IKEv2는 서로 다른 RRAS 인증서 제어를 사용합니다

«VPN 인증서»를 바꾸면 잘못된 서비스를 변경할 수 있습니다. RRAS는 최소 세 가지 인증서 제어를 유지하며, 각각 다른 프로토콜과 다른 연결 역할에 속합니다. 프로토콜을 먼저 특정하면 위험한 추측이 한 번의 되돌릴 수 있는 바인딩 변경이 됩니다. 아래의 모든 내용은 그 한 문장에 달려 있습니다.

인증서보다 프로토콜을 먼저 특정하세요

SSTP 수신기는 HTTPS처럼 동작하는 클라이언트에 TLS 인증서를 제시합니다. 들어오는 사이트 간 IKEv2 연결은 서버 ID를 알리고 피어 인증서를 신뢰할 수 있는 루트에 대해 검증합니다. 인터페이스별 사이트 간 정의는 자체 머신 ID를 가집니다.

이것은 세 가지 범위를 가진 세 가지 제어입니다. 이를 혼동하면 한 프로토콜에서는 동작하는 것처럼 보이고 다른 프로토콜에는 전혀 효과가 없는 변경이 생기며, 이는 명백한 실패보다 나쁩니다. 무엇이든 건드리기 전에 어느 프로토콜이 실패했는지, 어느 쪽이 인증서를 제시했는지, 어느 쪽이 거부했는지 기록하세요.

SSTP는 HTTPS 바인딩입니다

지원되는 Remote Access 배포에서 Set-RemoteAccess는 SSTP 연결과 HTTPS 관련 DirectAccess 역할에 사용되는 SslCertificate 매개 변수를 노출합니다.

검증 및 배포 범위는 Remote Access 구성을 따르므로 한 번의 바인딩 변경이 하나 이상의 연결이나 노드에 적용될 수 있습니다. 부하 분산 배포에서는 그 범위에 구성이 포함하는 모든 노드가 들어갑니다. 노드 하나를 바꾸고 클라이언트 하나만 테스트하면 나머지는 이전 리프를 계속 제시하며, 이는 유지 관리 기간을 넘겨 남는 반쪽짜리 변경입니다.

업데이트 전에 예상 서비스 이름, 체인, 유효 기간, 의도된 용도, 개인 키 사용 가능 여부를 확인하세요. 인증서는 클라이언트가 확인할 이름과 일치해야 하며, 어댑터 레이블은 그 이름이 아닙니다.

들어오는 IKEv2에는 자체 매개 변수가 있습니다

Set-VpnAuthProtocol는 들어오는 사이트 간 IKEv2 인증을 구성하고, CertificateAdvertised는 터널 인증 모드가 이를 사용할 때 인증서를 제공합니다. 이것은 호스트의 아무 서버 인증서나 선택하는 일반 명령이 아닙니다.

두 개체를 분리하세요. 서버가 자신의 ID로 제시하는 리프와, 피어 인증서를 받아들이는 데 사용하는 루트입니다. 어느 발급자를 신뢰할지 고르는 것은 서버가 어느 리프를 제시하는지에 대해 아무것도 말하지 않습니다.

개별 사이트 간 인터페이스의 ID는 Set-VpnS2SInterface를 통해 설정합니다. 같은 머신의 같은 저장소에 둘 다 있어도 자동으로 SSTP 인증서가 되지는 않습니다.

먼저 후보를 검사하세요

로컬 컴퓨터 저장소를 집중해서 보면 비공개 항목을 내보내지 않고 공개 메타데이터를 확인할 수 있습니다.

Get-ChildItem Cert:\LocalMachine\My |
    Select-Object Thumbprint, Subject, HasPrivateKey, NotAfter

그 목록은 출발점이며 적합성 테스트가 아닙니다. 구성하는 프로토콜에 대해 SAN 항목, 확장 키 사용, 체인, 서비스 계정의 개인 키 접근을 검사하세요.

관련 없는 클라우드 클라이언트 ID용으로 설치된 인증서는 같은 저장소에 나타난다는 이유만으로 적합하지 않습니다. 가시성은 적합성이 아니며, 화면 캡처의 지문은 서비스 계정이 키를 읽을 수 있는지 아무것도 증명하지 않습니다. 그 접근을 명시적으로 확인하세요. 키 권한이 없으면 서비스가 다시 시작되어 인증서를 사용하려 할 때에야 실패합니다.

현재 바인딩을 기록하고 변경하기 전에 다른 방법으로 호스트에 접근할 수 있는지 확인하세요. 복구 경로는 변경의 일부이며, 뒤따르는 사고의 일부가 아닙니다.

갱신은 활성화가 아닙니다

인증서를 다시 발급하는 것은 실행 중인 서비스에 대해 인증서를 선택하는 것과 다른 작업입니다. 새 리프는 의도된 DNS ID를 유지하면서도 다른 지문을 가질 수 있으므로 바인딩이 업데이트되기 전에는 아무것도 이를 가리키지 않습니다. 갱신은 개체를 바꾸고, 활성화는 그 개체에 대한 참조를 바꿉니다. 이 둘을 혼동하면 올바르게 갱신된 인증서가 몇 주 동안 사용되지 않은 채 남을 수 있습니다.

지원되는 변경을 적절한 기간에 문서화된 재시작을 포함해 적용한 다음, 의도한 프로토콜의 새 연결에서 인증서를 검사하세요. 캐시된 클라이언트 세션은 이전 리프를 계속 표시하여 올바른 변경을 고장처럼 보이게 할 수 있습니다.

이전 인증서는 그 확인이 통과된 후에만 일반 절차로 폐기하세요. Set-RemoteAccess 참조에는 부하 분산 배포에서의 영향을 포함한 SSL 매개 변수의 범위가 문서화되어 있으며, 바인딩 변경 전에 읽을 가치가 있는 부분이 바로 그것입니다.