Mac VPN이 한 번만 연결되고 시간 초과됩니다: IKE 데몬 정리

재부팅 후 첫 연결은 작동합니다. 그 뒤의 모든 시도는 연결 단계에서 멈추고 결국 시간 초과되며, 유일하게 믿을 수 있는 해결책은 또 한 번 재부팅하는 것입니다. 이 패턴은 프로필 문제도 아니고 자격 증명 문제도 아닙니다. 백그라운드의 무언가가 이전 시도의 상태를 여전히 붙들고 있고, 다음 시도가 그것과 충돌합니다.

macOS에서 그 무언가는 보통 IKE 데몬입니다.

패턴: 한 번 연결된 뒤 시간 초과

부팅할 때마다 정확히 한 번 작동하는 연결은 연결 해제로는 살아남지만 재부팅으로는 사라지는 상태를 가리킵니다. 프로필은 둘 다 견디므로 프로필은 변수가 아닙니다. 자격 증명도 둘 다 견디지만 서버가 계정을 잠그면 다릅니다. 재부팅에서 바뀌는 것은 실행 중인 데몬의 집합과 그들이 붙들고 있는 소켓입니다.

이것은 로그를 하나도 열기 전에 조사 범위를 좁힙니다. 질문은 어떤 프로세스가 IKE 포트를 소유하며 무엇을 하고 있다고 생각하는가가 됩니다.

데몬 둘, 포트 하나

시스템은 실행합니다 racoon 연결이 IKE 버전 1로 말할 때. 현재 릴리스는 또한 가져옵니다 iked IKEv2와 더 새로운 IPsec 스택을 위해서도. 둘 다 UDP 500과 UDP 4500을 점유할 수 있고, 연결 시도가 암호 프롬프트에서 취소되거나 네트워크 변경으로 중단된 뒤에도 둘 다 반쯤 열린 보안 연결을 유지할 수 있습니다.

그런 일이 생기면 다음 시도는 깨끗하게 시작되지 않습니다. 이전 연결이 여전히 피어의 상태를 차지한 상태에서 협상을 시도하고, 교환은 명확한 오류로 실패하지 않고 멈춰 버립니다. 사용자는 회전 표시를 본 뒤 시간 초과를 봅니다.

무언가를 죽이기 전에 소유자를 찾으세요. 그 답이 어떤 서비스를 다시 시작하고 다음에 어떤 로그를 읽을지 결정합니다.

sudo lsof -i :500 -i :4500
ps -ef | grep -E "racoon|iked"

출력을 두 가지 사실로 읽으세요. 어떤 프로세스가 포트를 붙들고 있는지, 그리고 하나 이상 존재하는지. 같은 소켓을 두고 경쟁하는 IKE 데몬 둘은 불안정한 서버처럼 보이는 간헐적 동작을 많이 설명합니다.

프로세스가 아니라 작업을 다시 시작하세요

오래된 시스템에서는 프로세스를 죽이고 다음 연결이 그것을 다시 시작하도록 두면 충분합니다. 현재 릴리스에서는 데몬을 launchd가 관리하고, 프로세스에만 신호를 보내면 작업이 실행 중이지도 않고 시작 예정도 아닌 상태로 남을 수 있습니다. 대신 작업을 멈추고 시작하세요.

sudo launchctl stop com.apple.racoon
sudo launchctl start com.apple.racoon

launchd에 작업 기록이 없으면 프로세스를 이름으로 죽이는 것만으로도 다음 시도에서 새 협상이 강제됩니다. 검사는 두 경우 모두 같습니다. 다시 연결을 시도할 때 어떤 프로세스도 포트를 붙들고 있으면 안 됩니다. 같은 명령으로 그것을 확인하세요 lsof 재부팅이 성공했다고 가정하는 대신.

그다음 한 번 연결하고 클라이언트 로그를 처음부터 읽으세요. 1단계를 지나 전송 실패를 보고하는 협상은 로컬 소켓 문제를 반복하는 것입니다; 피어가 거부한 협상 은 완전히 다른 티켓입니다.

서버가 거부하는 쪽일 때

두 번째 연결이 모두 로컬에서 실패하는 것은 아닙니다. 서버는 연결 해제 후 정해진 창 동안 새 로그인을 거부할 수 있고, 클라이언트의 시간 초과는 멈춘 데몬과 똑같이 보입니다. 구분은 간단합니다. 데몬 재시작이 도움이 되지 않는데 다른 계정이 즉시 연결된다면 그 창은 서버 측이고 Mac은 애초에 문제가 아니었습니다.

분할 터널 정책은 반대 방향에서 같은 형태를 만듭니다. 모든 트래픽을 터널에 요구하는 서버는 분할 터널로 설정된 클라이언트를 협상 중에 끊어 버리고, 클라이언트는 정책 거부가 아니라 시간 초과를 보고합니다. 프로필을 바꿔 모든 것을 터널로 보내면 연결될 수 있지만, 그것은 네트워크 소유자와 함께 내릴 정책 결정이지 조용히 적용할 수리가 아닙니다.

클라이언트를 다시 바꾸기 전에 피어 로그를 읽으세요. 거부, 정책 불일치, 조용한 끊김은 세 가지 다른 원인이며 Mac 화면에서는 모두 “연결 중”으로 보입니다.

오래된 클라이언트와 64비트 커널

구형 Cisco IPSec 클라이언트는 32비트 및 PowerPC 시스템용으로 빌드된 커널 확장을 로드합니다. 64비트 커널로 부팅한 Mac에서는 그 확장을 로드할 수 없고, 클라이언트는 VPN 하위 시스템에 전혀 도달하지 못해 오류 51로 일찍 실패합니다. 잘못된 아키텍처의 커널 확장은 데몬을 몇 번을 다시 시작해도 고쳐지지 않습니다.

확장을 다시 로드하면 잠시 작동하다가 다음 부팅에서 다시 실패할 수 있습니다. 지속적인 답은 아직 지원되는 환경에서 오래된 커널을 실행하거나 시스템과 함께 제공되는 내장 클라이언트로 옮기는 것입니다. 로드되지 않는 타사 클라이언트에 저녁을 쓰기 전에 아키텍처를 확인하세요.

• 한 번 재현하고, 프로필을 건드리기 전에 어느 데몬이 UDP 500을 소유하는지 확인하세요.
• 1단계 이후 첫 실패를 읽으세요. 전송 오류는 로컬 소켓을 가리킵니다.
• 프로세스만이 아니라 launchd 작업을 다시 시작하고 포트가 비어 있는지 확인하세요.
• 서버 측 재인증 창을 클라이언트 결함과 분리하려고 두 번째 계정을 시도해 보세요.
• 클라이언트를 탓하기 전에 커널 아키텍처를 기록하세요.

정확히 한 번만 작동하는 VPN은 반증될 때까지 상태 문제입니다. 데몬을 정리하는 것이 재부팅보다 빠르고, 재부팅이 버렸을 로그 증거를 보존합니다.