strongSwan IKEv2 VPN에서 한 iOS 클라이언트가 고정 IP를 못 받고 있었는데 서버 swanctl.conf의 remote.id를 FQDN 형식으로 바꾸니 해결됐다. 그러면 나머지 여섯 대도 같이 고쳐야 하는지가 다음 판단이었다.
Table of contents
Open Table of contents
퍼뜨리기 전의 확인
같은 증상이 없더라도 형식을 통일하는 편이 낫지 않을까 싶었지만 확인부터 하기로 했다. 먼저 나머지 여섯 대가 어느 플랫폼인지 물었다.
전부 두 종류였고 방금 고친 iOS는 하나도 없었다. 여기서 이미 일괄 적용의 전제가 흔들렸다.
검증 — 접속 세션과 설정 파일
마침 한 대가 접속 중이라 swanctl --list-sas 출력을 봤다. 대괄호 안이 C=KR, O=…, CN=… 인증서 주체 DN 형식이었고 FQDN 형식이 아니었으며 고정 IP도 정상으로 받고 있었다.
접속 중이 아닌 것들은 클라이언트 쪽 swanctl.conf를 열었는데 local.id 항목 자체가 없었다. strongSwan 공식 문서를 찾아보니 id가 없으면 인증서의 subject DN을 식별자로 쓴다고 돼 있어서 이쪽도 인증서 주체 형식이었다.
원인 — 세 플랫폼의 대조표
셋을 정리하니 방금 고친 iOS만 LocalIdentifier를 .mobileconfig 구성 프로파일에 평문으로 싣고 나머지 둘은 인증서 주체 DN 형식이었다. 그중 하나는 swanctl.conf에 id가 없으면 자동으로 그렇게 동작한다.
두 가지 방법이 있었는데 여섯 대의 remote.id도 FQDN으로 통일하는 것과 지금 잘 되는 것을 그대로 두는 것이다. 뒤쪽을 골랐다. 이유는 나머지 여섯 대는 인증서 주체 DN을 보내는데 설정이 FQDN을 기대하게 되면 매칭이 실패해서다. 인증이 거부되므로 지금 잘 되는 여섯 대가 전부 안 됐을 것이다. 대신 서버 설정에 두 형식이 섞여 남는 것을 감수했고 결론은 수정 없음이었다.
판단 기준 — 판별 순서와 기기 이름의 함정
앞으로 이것을 어떻게 가를지도 적어 뒀다. 접속 중이면 swanctl --list-sas 출력에서 대괄호 안을 보고 인증서 주체 DN 형식인지 FQDN 형식인지를 가른다.
접속 중이 아니면 클라이언트 swanctl.conf에서 id 항목의 유무를 본다. 앞쪽이 실제로 무엇을 보내고 있는지를 알려 주므로 더 확실하다.
함정이 하나 있었는데 기기 이름이 플랫폼을 알려 주지 않는다는 것이다. 이름만 보고 짐작하면 틀리므로 사용자에게 물어 여섯 대의 플랫폼을 확정했다. 내가 알 수 없는 것은 물어보는 것이 조사이고 추측으로 채우는 것이 아니다.
결과 — 수정 없음
이 조사의 결과가 아무것도 안 하는 것이었지만 하지 말아야 할 작업을 막았다. 확인하지 않았으면 여섯 대 설정을 바꾸고 전부 접속 불가가 되어 원상 복구와 원인 조사가 이어졌을 것이다.
처음 고칠 때 나는 이렇게 하니 된다는 데서 멈추고 왜 되는지는 몰랐다. iOS가 LocalIdentifier의 FQDN을 보내기 때문이었고 다른 플랫폼은 다른 것을 보낸다. 왜 먹혔는지를 알았으면 퍼뜨릴지 말지가 바로 정해졌을 텐데 몰랐으므로 확인이 필요했다.
정리
- 플랫폼마다 클라이언트 식별자 타입이 달라서 한 처방을 일반화하면 안 된다
- 한 대에서 먹힌 처방을 퍼뜨리기 전에 나머지가 같은 조건인지 확인한다
- 접속 중이면
swanctl --list-sas출력으로 판별하는 것이 가장 확실하다 - 접속 중이 아니면 클라이언트
swanctl.conf에서id유무를 본다 id가 없으면 인증서 subject DN을 자동으로 쓰는 플랫폼이 있다- 기기 이름이 플랫폼을 알려 주지 않으므로 물어본다
- 조사 결과가 수정 없음이어도 값어치를 한다
- 왜 먹혔는지를 알면 퍼뜨릴지 말지가 바로 정해진다