네트워크가 바뀔 때 MOBIKE가 IKEv2 VPN을 살려 두는 방법

휴대폰이 Wi-Fi를 떠나 셀룰러 망에 접속하고, 노트북이 Ethernet에서 핫스폿으로 옮겨 가며, IKEv2 터널은 살아남거나 그렇지 않습니다. MOBIKE는 처음부터 다시 시작하는 대신 원본 주소가 바뀌었다고 원격 측에 알려 터널이 살아남게 하는 확장입니다. 그것이 하지 않는 일은 변화가 진행되는 동안 모든 애플리케이션을 살려 두는 것입니다. 이는 두 가지 주장이며, 사람들이 보통 말하는 것은 두 번째입니다.

각 단계는 다르게 실패하기 때문에 전환을 단계별로 살펴보십시오.

갱신이 실제로 바꾸는 것

보안 연결이 아직 유효한 동안 개시자는 새 주소를 알아내고 응답자에게 갱신을 보내며, 응답자는 그 주소를 같은 연결에 사용합니다. 보안 매개변수는 처음부터 다시 협상되지 않습니다. 이것이 전부입니다. 새로운 인증 라운드도, 새로운 키 교환도, 사용자에게 묻는 일도 없습니다. 이는 살아남은 상태가 여전히 이전 세션에 속한다는 뜻이기도 합니다.

MOBIKE는 트래픽을 UDP 캡슐화로 옮길 수도 있으며, 그래서 동작하던 터널이 네트워크 변경 후 때때로 4500 포트를 쓰기 시작합니다. 그 전환만으로 NAT가 탐지되었다는 증거가 되지는 않지만, 둘은 자주 함께 나타납니다.

프로필이 정말로 그것을 켜는가

양쪽 피어가 확장을 지원해야 하고, 배포가 그것을 켜야 합니다. strongSwan에서는 동작이 연결별로 설정할 수 있으며, 인터페이스나 경로 변경이 필요할 때 경로 탐색과 갱신을 촉발할 수 있습니다. 모든 IKEv2 프로필이 그것을 켠다고 가정하지 말고 연결의 실제 설정을 확인하십시오. 이 기능보다 오래된 안내서에서 복사한 프로필이 흔한 원인입니다.

양쪽 끝에서 협상된 상태가 권위이며, 제품군의 문서가 아닙니다.

전환을 단계별로 살펴보기

네트워크를 옮기기 전에 애플리케이션의 상태를 기록하십시오. 그다음 옮기고, 이후에 클라이언트와 서버의 상태를 기록하십시오. 사라진 주소, 닿을 수 없는 피어, 스스로 세션을 다시 연결해야 하는 애플리케이션은 세 가지 다른 결과입니다. 처음 두 가지만 VPN 계층에 속하고, 세 번째는 애플리케이션이 쓰는 프로토콜에 속합니다.

네트워크 전환을 정지 상태 시험과 비교해 어떤 사건이 문제를 일으키는지 알아 두십시오. 최종 네트워크에서의 처리량 측정은 전환을 재현할 수 없습니다. 그것은 목적지를 재는 것이지 여정을 재는 것이 아닙니다.

실패 계층을 분리하기

오래 유지되는 TCP 세션은 IKEv2 교환 밖의 이유로 실패할 수 있습니다. 새 네트워크는 다르게 필터링하고, 다르게 해석하고, 다르게 라우팅할 수 있습니다. 터널 주소는 전혀 바뀌지 않는데 그 아래 경로가 바뀔 수도 있습니다. 그래서 애플리케이션 재연결이 VPN이 깨뜨리지 않은 것을 고칠 수 있습니다.

복구하는 동안에도 차단 정책을 그대로 두십시오.

자동 이동성과 직접 트래픽을 막는 규칙은 서로 다른 제어이며, 첫 번째를 동작시키려고 두 번째를 끄는 것은 나쁜 거래입니다. 이동성 갱신이 실패하면 터널 주위로 트래픽이 새어 나가게 두는 대신 차단이 유지되어야 합니다.

반복될 때 무엇을 기록할지

양쪽에서 타임스탬프와 두 주소 값을 보관하십시오. 그 기록은 애플리케이션이 접촉을 잃기 전에 갱신이 끝났는지 보여 주며, 이것이 이동성 버그와 애플리케이션 시간 초과의 차이입니다. 그다음 전환 방향을 비교하십시오. Wi-Fi를 떠나 셀룰러로 가는 것은 그 반대와 대칭이 아닙니다. 한 방향은 동작하고 다른 방향은 실패할 수 있습니다.

그 비대칭은 가장 먼저 시험할 일이 될 만큼 흔합니다.

기록을 손에 쥐면 사건은 또 하나의 끊긴 아이콘이기를 그치고 알려진 소유자가 있는 연속 속의 한 사건이 됩니다. 그리고 그것이 한 번의 둘러보기가 정직하게 약속할 수 있는 전부입니다.