iPhone Always On VPN: 두 터널이 하나의 가상 IP를 공유할 수 있는 경우

관리되는 Always On 프로필을 사용하는 감독 대상 iPhone에서는 전화기가 활성 IP 인터페이스마다 터널을 유지하므로 셀룰러와 Wi-Fi가 각각 자신의 터널을 갖습니다. 그러면 서버에는 한 기기에 대해 두 개의 IKE 보안 연결이 나열되고, 흔히 하나의 가상 주소를 공유합니다. 첫 직감은 이것을 rekey 루프라고 부르고 타이머를 바꾸기 시작하는 것이지만, 그 직감은 대개 틀립니다. 아래 단계를 서버에 증거가 나타나는 순서대로 따라가고, 서버가 어떤 사례인지 알려줄 때까지 전화기 설정은 그대로 두세요.

서버가 이미 가지고 있는 두 행부터 시작하세요

연결을 swanctl --list-sas 로 나열하고 두 항목에서 원격 주소, 인증된 ID, 할당된 가상 IP, 생성 시각이라는 네 개의 필드를 읽으세요. 하나의 ID와 하나의 가상 IP에 대해 서로 다른 두 개의 외부 주소가 이 질문을 시작한 형태이며, 어떤 변경 전에든 적어 둘 가치가 있습니다. 그다음 트래픽 선택기가 목적지 조회로 두 터널을 구분할 수 있는지 결정하므로 각각에 붙은 자식 연결을 확인하세요. 몇 초 안에 나타났다 사라지는 쌍은 둘 다 몇 시간씩 사는 쌍과 다른 동물입니다.

결론을 내리기 전에 목록을 생성 시각으로 정렬하세요. 출력에서의 인접성은 아무 의미도 없고, 표 형태의 목록은 바로 그 실수를 부릅니다.

어떤 겹침을 보고 있는지 판단하세요

IKEv2 rekey와 make-before-break 재인증은 옛 연결을 삭제하기 전에 새 연결을 세워 짧은 겹침을 의도적으로 만듭니다. 타임스탬프가 사례를 가르는데, 새 연결이 나타난 뒤 한두 초 후에 사라지는 옛 SA는 제 역할을 하는 갱신이기 때문입니다. 독립적인 인터페이스 터널은 결코 그렇게 보이지 않으며, 각각은 자신의 인터페이스가 살아 있는 동안 유지되고 하나를 삭제한다고 다른 하나가 생성되지는 않기 때문입니다.

Apple의 관리되는 Always On 동작은 인터페이스별이므로 감독 대상 기기가 수동으로 설정한 프로필보다 정당하게 더 바빠 보일 수 있습니다. 공급자 앱의 자동 연결 토글이 같은 뜻은 아니고, 일반적인 on-demand 규칙도 마찬가지입니다. Apple 배포 개요가 인터페이스별 모델을 설명하므로 루프라고 가정하기 전에 두 행을 그것과 비교하세요. 두 형태 모두 같은 서버 풀에서 가져오므로 겹침이 유일한 조기 신호입니다.

하나의 가상 주소가 두 터널의 응답을 깨는 이유를 보세요

전화기로 가는 응답은 내부 주소로 지정되고, 커널은 목적지와 정책으로 나가는 터널을 고르며, 전화기가 사용한 인터페이스로 고르지 않습니다. 같은 가상 IP를 유지하고 정책이 겹치는 두 개의 동시 연결은 응답이 어느 세션에 속하는지 라우팅 결정이 말할 방법을 남기지 않습니다. 일부 응답은 잘못된 터널을 타고, 전화기는 한 방향으로만 작동하거나 Wi-Fi가 올라오면 끊기는 연결을 보여 줍니다. 두 명령 출력이 상태를 증명하는데, swanctl --list-sas 는 두 SA에서 같은 가상 IP를 보여 주고 ip xfrm policy 는 두 개의 동일한 선택기를 보여 줍니다.

바로 그 출력 쌍을 변경 기록에 붙여 넣습니다. 어느 하나만으로는 설득력이 없는데, 각각은 따로 보면 그럴듯해 보일 수 있기 때문입니다.

이것은 서버 측 주소 지정과 정책이며 전화기의 오작동이 아니고, 어떤 클라이언트 설정도 두 개의 동일한 내부 주소를 분리하지 못합니다. 풀이 같은 값을 두 번 내주었고 정책 설치기가 그것을 받아들였습니다. 클라이언트를 탓하기 전에 서버 쪽에서 결과를 읽으세요.

풀이나 동시성 모델을 바꾸세요, rekey 타이머가 아니라

swanctl 구성에서 고유성은 연결에 대한 명시적 정책입니다. unique = replace 는 새 연결이 설정될 때 더 오래된 연결을 제거하고, unique = keep 는 새로 온 연결을 거부하며, 두 값 모두 연결을 설정할 때 작동하고 그 안의 자식 SA에는 작동하지 않습니다.

connections {
  ios-alwayson {
    unique = replace
  }
}

어느 값도 인터페이스별 클라이언트에 중립적이지 않습니다. keep 는 두 번째 터널을 거부해 깔끔한 상태 화면을 되돌리지만 관리되는 설계를 깨뜨리고, replace 는 더 오래된 터널을 무너뜨리며 반대 방향의 같은 타협입니다. 두 터널이 정말로 필요하다면 풀 백엔드가 하나의 ID에 서로 다른 임대를 발급해야 하고, 그 임대 키가 요청을 구분해야 합니다. 정적 ID 대 주소 표는 같은 주소를 두 번 돌려주며 원래 문제를 더 많은 구성으로 재현합니다. 두 번째 정적 매핑을 추가하기 전에 백엔드가 임대를 어떻게 키로 삼는지 확인하세요.

실제로 배포하는 전환을 시험하세요

세션을 활성화한 채 Wi-Fi 범위를 벗어났다가 다시 들어오고, 응답이 양방향으로 도착하는지 확인하세요. 두 번 하는데, 두 번째 전환이 오래된 정책이 보통 나타나는 지점이기 때문입니다. 그 연결에 응답하는 서비스로 시험하고, 터널이 유휴 상태로 있는 것이 아니라 트래픽을 실을 때 나가는 동작을 반복하세요. 보낼 수는 있지만 받지 못하는 전화기는 핸드셰이크 로그에서는 건강해 보이고 브라우저에서는 고장 나 보입니다.

한 행으로 줄어든 상태 화면은 작동하는 설계의 증거가 아니라 터널 하나가 사라졌다는 증거일 뿐입니다. 전환이 통과하려면 양방향이 모두 작동해야 합니다. 관찰한 내용을 겹침 점검의 두 출력과 함께 적어 두어 다음 엔지니어가 같은 산책을 반복하는 대신 비교할 수 있게 하세요.