Windows의 .pbk 파일은 무엇에 속하는가 (그리고 무엇에 속하지 않는가)
.pbk 파일은 하나의 프로필이나 RRAS 서버가 소유한 전화 번호부이며, 이식 가능한 VPN 스키마가 아닙니다. 소유자, 섹션, 노출되는 속성을 읽으십시오.
검색 결과는 .pbk 파일을 건네주고, 키 이름은 익숙해 보이며, 뻔한 다음 수는 그것을 모든 Windows VPN을 위한 이식 가능한 스키마로 취급하는 것이다. 그렇지 않다. 형식은 소유자에게 속하며, 같은 키라도 어느 소유자가 썼는지에 따라 다른 의미를 갖는다. 범위를 먼저 읽는 것이 문서 작업을 지원되지 않는 편집으로 바꾸지 않게 하는 조건이다.
네 명의 소유자, 네 명의 다른 판독자
네 명의 서로 다른 소유자가 비슷하게 보이는 파일을 쓴다. 사용자별 네이티브 연결은 현재 사용자의 전화 번호부로 들어가고, 모든 사용자용 연결은 호스트의 모든 계정이 읽을 수 있는 컴퓨터 수준 저장소로 들어간다. RRAS 서버는 자체 라우팅 역할을 위한 요청 시 전화 걸기 구성을 보관하고, 타사 클라이언트는 확장자만 공유하는 자체 형식을 보관할 수 있다. 같은 확장자, 네 명의 판독자, 네 벌의 규칙.
일치하는 표시 이름이 두 항목을 같은 항목으로 만들지 않으며, 그들 사이에 키를 복사하는 것은 관리자가 문서화한 적 없는 무언가를 존중한다고 가정한다. 소유자는 누가 파일을 바꿀 수 있는지도 결정한다. 사용자별 프로필은 사용자의 선택이고, 컴퓨터 수준 프로필은 관리 결정이며, 서버의 요청 시 전화 걸기 항목은 자체 변경 관리 아래에 있는 라우팅 구성이다. 그래서 소유권 실수는 형식 문제가 되기 전에 권한 문제가 된다.
파일 자체가 아니라 연결을 관리하는 구성 요소를 보고 소유자를 결정하라. 파일은 산출물이고, 어떤 키를 언제 읽는지는 관리 구성 요소가 정한다. 산출물을 먼저 읽고 관리자를 나중에 읽는 것이 아무것도 묻지 않는 필드를 편집하게 되는 경로다.
공개된 형식이 당신의 파일을 설명하기를 멈추는 곳
RRAS 관리 프로토콜에서 전화 번호부는 관리 클라이언트가 쓰고 라우팅 서비스가 읽는 일반 텍스트이므로, MS-RRASM 사양은 데스크톱 프로필이 아니라 서버를 위한 요청 시 전화 걸기 설정을 설명한다. 구조가 평면적 읽기가 파괴하는 부분이다. 한 항목은 여러 미디어 블록을 가질 수 있고, 각 블록은 장치 블록을 가지며, 그것은 다시 개별 번호의 블록을 갖는다. 따라서 같은 키가 여러 위치에서 다른 의미로 나타날 수 있다.
키를 해당 섹션 및 버전 노트와 함께 읽고, 데스크톱 인터페이스의 같은 이름 확인란에서 값을 옮겨 쓰지 마라. 문서에서 익숙한 키를 찾는 것이 관련 없는 네이티브 프로필의 모든 필드를 덮는다는 것을 증명하지 않는다. 섹션 규칙도 데스크톱 전화 번호부를 서버 형식으로 다시 쓰라는 허가가 아니다.
| Owner | What reads the file | What a key means there |
|---|---|---|
| Per-user native connection | The user's own connection manager | A property of that user profile |
| All-user native connection | The machine-wide connection store | A property shared by everyone on the host |
| RRAS demand-dial | The RRAS service, using the documented hierarchy | A field inside a media, device or number section |
| Third-party client | That vendor's own parser | Whatever that vendor documents, if anything |
표는 사양이 아니라 읽기 보조 수단이다. 어떤 판독자에게 물어야 하는지 알려주고, 판독자는 그 필드가 무엇을 뜻하는지 알려준다. 그 판독자가 타사 파서라면, 아무 공개 자료도 그 필드를 전혀 문서화하지 않는다는 것이 정직한 답일 수 있다.
파일이 아니라 Windows에 물어라
네이티브 연결이라면 파일을 읽는 대신 Windows에 프로필을 요청하라. 형식화된 속성이 문서화된 표면이며 지원되는 변경이 수정하는 유일한 대상이다. 아래 두 명령은 두 네이티브 저장소을 각각 읽는다. 프로필이 두 저장소 어디에도 없다면 그것을 관리하는 클라이언트가 네이티브 메커니즘을 쓰지 않는 것이며 어떤 네이티브 cmdlet도 그것을 설명하지 않는다.
Get-VpnConnection -Name 'Field Ops'
Get-VpnConnection -AllUserConnection | Select-Object Name, ServerAddress, TunnelType검사가 아니라 배포를 위한 문서화된 경로는 이름 있는 스키마를 가진 관리형 프로필 설정이며, 텍스트나 이진 블롭 내부의 숫자 편집이 아니다. 프로필 정의는 지원되는 설정을 설명하고, 프로필이 의존하는 인증서와 개인 키를 제공하지는 않는다. 등록은 자체 권한을 가진 별도 프로세스이며, 전화 번호부 키를 이해하는 것이 개인 키를 배포한 적은 없다. 두 경로를 따로 계획하지 않으면 첫 인증서 배포가 두 번째 사고가 된다.
하나의 속성, 그리고 그 주변의 수명 주기
저장된 값은 적용된 값이 아니다. 승인된 변경 후에는 새 연결을 열고 프로필이 설치하는 경로, 상속하는 해석기 정책, 그리고 활성화해야 했던 작업을 확인하라. 이미 올라와 있던 세션을 재사용하면 오래된 설정을 시험하게 되어 거짓 음성을 낳는다.
원시 파일 작업을 하기 전에 파일을 옆으로 복사하라. 항목이 여럿인 전화 번호부는 공유 산출물이며, 파일 전체를 다시 쓰는 표적 편집은 변경 자체보다 큰 영향 범위를 갖는다. 관련 없는 항목은 그대로 두고, 새 구성이 검증될 때까지 원래의 보호된 구성을 유지하라. 필수 필드가 실제로 보유한 소유자와 릴리스에 대해 문서화되어 있지 않다면 열린 지원 질문으로 기록하라. 다른 컴퓨터의 파일에서 인코딩을 지어내는 것이 바로 동작하는 프로필을 기준점 없는 디버깅 프로젝트로 만드는 길이다.
규율은 모든 단계에서 같다. 소유자를 지목하고, 섹션을 지목하고, 그다음 지원되는 작업을 지목하라. 그 밖의 것은 인용을 붙여 둔 추측일 뿐이다.