두 iPhone에 같은 IKEv2 ID? 번갈아 연결되는 이유

스마트폰 두 대, 프로필 하나, 그리고 누군가 게이트웨이를 보기 전까지 초자연적으로 보이는 패턴. 한 기기가 터널을 유지하고 두 번째가 연결되면 첫 번째는 몇 초 안에 그것을 잃는다. 첫 번째가 다시 연결되고 두 번째가 끊긴다. 배터리 절약, Wi-Fi 로밍, 통신사 NAT가 의심받지만 진짜 원인은 다른 모든 것과 함께 복사된 텍스트 필드에 있다. IKEv2는 peer를 이름으로 식별하고, 두 스마트폰이 같은 이름을 제시하고 있다.

ID는 서버가 당신을 저장하는 키다

IKEv2 교환에서 각 측은 자신이 누구인지 밝힌다. 개시자는 로컬 식별자를 보내고, 응답자는 자신의 식별자로 응답하며, 응답자는 개시자가 주장한 신원을 정책에 비추어 검사한다. 게이트웨이는 기기 단위가 아니라 신원 단위로 상태를 유지한다. 기기는 게이트웨이가 볼 수 있는 것이 아니기 때문이다. 그래서 같은 식별자를 가진 두 기기는 하나의 peer로 도착하고, 두 번째 교환은 첫 번째를 덮어써야 한다. 문제는 둘 다 사용 중일 때만 나타나며, 그래서 기기 한 대 테스트로는 절대 재현되지 않는다.

이 중 어느 것도 클라이언트의 버그가 아니다. 클라이언트는 프로필이 시킨 대로 정확히 보냈다.

게이트웨이에서 충돌이 보이는 모습

두 스마트폰이 깨어 있고 사용 중일 때 peer 목록을 보라. 충돌은 기기가 번갈아 바뀌면서 주소가 변하는 항목 하나만 보여 주고, 활성 세션 카운터는 결코 둘에 도달하지 않는다. 요청 시 해제는 다르게 보이며, 둘을 구분하려면 이론이 아니라 관찰 한 번이면 된다.

일어나는 동안 두 사건을 타임스탬프와 함께 기록하라. 다른 기기의 연결과 맞물리는 끊김은 식별자를 가리키고, 마지막 패킷 뒤 유휴 간격 하나가 지나 도착하는 끊김은 타이머를 가리킨다.

중복은 어디서 오는가

작동하는 구성 하나를 내보내고 서버 주소만 편집하면 첫 파일의 신원이 여전히 들어 있는 두 번째 파일이 만들어진다. 이것이 이 고장으로 가는 흔한 경로이며, 보통 작은 그룹을 서둘러 온보딩할 때 일어난다.

필드 이름 때문에 놓치기 쉽다. 원격 식별자는 기기가 기대하는 게이트웨이의 이름을 지정하며, 그것을 복사하는 것은 옳다. 로컬 식별자는 이 기기를 게이트웨이에 이름 붙인다 그리고 바로 그 값을 복사하는 것이 문제의 전부다.

기기별로 값을 발급하라

기기에 고유하고 수명 내내 안정적인 것을 사용하라. 예를 들어 인벤토리의 기기 식별자나 관리 시스템이 등록마다 생성하는 값이다. 부서 라벨, 공유 서비스 계정 이름, 사용자 이메일 주소는 그 사람에게 두 번째 기기가 생기는 순간 모두 충돌한다.

파일 하나를 배포하는 대신 기기별로 페이로드를 생성하라. 어떤 값이 어느 기기에 속하는지 기록해 두어, 교체가 예전 프로필을 복원해 새 기기를 곧바로 같은 충돌로 되돌리지 않게 하라.

서버 쪽도 확인하라. 신원을 고정 터널 주소에 매핑하는 게이트웨이는 두 개의 서로 다른 식별자가 같은 할당을 받으면 여전히 충돌할 수 있으므로, 풀에 여유가 있고 할당이 사용자별로 고정되어 있지 않은지 확인하라.

두 스마트폰을 깨운 상태로 검증하라

첫 번째를 연결해 사설 리소스에 도달한 뒤 두 번째를 연결하고 둘 다 일 분 동안 유휴로 두라. 두 세션이 모두 유지되고 peer 목록에 두 신원이 보여야 한다. 그런 다음 각 기기를 잠그고 풀어 유휴 경우가 여전히 제대로 동작하는지 확인하라.

다른 어떤 것도 연결되지 않는데 한 세션이 여전히 하루에 한 번 끊긴다면, 신원은 더 이상 용의자가 아니다. 프로필을 다시 편집하는 대신 유휴 타이머와 서버 세션 한도로 넘어가라.