플랫폼마다 다른 식별자 타입

VPN에서 한 클라이언트가 고정 IP를 못 받고 있었는데 설정에서 클라이언트 식별자 형식을 이름 형식으로 바꾸니 해결됐다. 그러면 나머지 여섯 대도 같이 고쳐야 하는지가 다음 판단이었다.

Open Table of contents

퍼뜨리기 전의 확인

같은 증상이 없더라도 형식을 통일하는 편이 낫지 않을까 싶었지만 확인부터 하기로 했다. 먼저 나머지 여섯 대가 어느 플랫폼인지 물었다.

전부 두 종류였고 방금 고친 플랫폼은 하나도 없었다. 여기서 이미 일괄 적용의 전제가 흔들렸다.

마침 한 대가 접속 중이라 상태 출력을 봤다. 대괄호 안이 인증서 주체 정보 형식이었고 이름 형식이 아니었으며 고정 IP도 정상으로 받고 있었다.

접속 중이 아닌 것들은 클라이언트 설정 파일을 열었는데 식별자 항목 자체가 없었다. 문서를 찾아보니 항목이 없으면 인증서의 주체 정보를 식별자로 쓴다고 돼 있어서 이쪽도 인증서 주체 형식이었다.

셋을 정리하니 방금 고친 플랫폼만 이름 형식을 구성 프로파일에 평문으로 싣고 나머지 둘은 인증서 주체 형식이었다. 그중 하나는 설정에 항목이 없으면 자동으로 그렇게 동작한다.

만약 통일하자며 전부 이름 형식으로 바꿨다면 나머지 여섯 대는 인증서 주체 형식을 보내는데 설정은 이름 형식을 기대하게 된다. 매칭이 실패해 인증이 거부되므로 지금 잘 되는 여섯 대가 전부 안 됐을 것이다. 결론은 수정 없음이었고 설정 파일을 손대지 않았다.

앞으로 이것을 어떻게 가를지도 적어 뒀다. 접속 중이면 상태 출력에서 대괄호 안을 보고 인증서 주체 형식인지 이름 형식인지를 가른다.

접속 중이 아니면 클라이언트 설정 파일에서 식별자 항목의 유무를 본다. 앞쪽이 실제로 무엇을 보내고 있는지를 알려 주므로 더 확실하다.

함정이 하나 있었는데 기기 이름이 플랫폼을 알려 주지 않는다는 것이다. 이름만 보고 짐작하면 틀리므로 사용자에게 물어 여섯 대의 플랫폼을 확정했다. 내가 알 수 없는 것은 물어보는 것이 조사이고 추측으로 채우는 것이 아니다.

이 조사의 결과가 아무것도 안 하는 것이었지만 하지 말아야 할 작업을 막았다. 확인하지 않았으면 여섯 대 설정을 바꾸고 전부 접속 불가가 되어 원상 복구와 원인 조사가 이어졌을 것이다.

처음 고칠 때 나는 이렇게 하니 된다는 데서 멈추고 왜 되는지는 몰랐다. 그 플랫폼이 이름 형식을 보내기 때문이었고 다른 플랫폼은 다른 것을 보낸다. 왜 먹혔는지를 알았으면 퍼뜨릴지 말지가 바로 정해졌을 텐데 몰랐으므로 확인이 필요했다.