strongSwan trap 모드: IPsec 터널이 트래픽을 기다리는 이유

상태 출력에 CHILD SA가 나타나지 않고 터널이 죽은 것처럼 보이다가, 원격 서브넷으로의 ping이 터널을 올립니다. 온디맨드 IPsec 구성에서 이 순서는 설계이며 결함이 아닙니다. trap 정책은 선택자를 설치하고 기다리며, 그와 일치하는 첫 패킷이 IKE와 CHILD SA 협상을 시작합니다.

혼란의 일부는 용어입니다. “up”은 서로 다른 두 상태에 쓰입니다. 구성이 로드되었고 커널 정책이 존재합니다만 데이터 연결은 없습니다. 활성 SA만 세는 모니터는 누군가 트래픽을 보내기 전까지 건강한 사이트를 다운으로 보고합니다.

대기 중인 온디맨드 터널에는 표시할 CHILD SA가 없습니다

trap 항목 자체는 아무것도 인증하지 않습니다. 커널에 선택된 트래픽의 정책을 유지하고, 패킷이 그 정책을 필요로 할 때 acquisition을 올리도록 요청합니다. 데몬은 acquisition을 받아 child 정의와 맞추고 거기서 협상을 진행합니다. 그때까지 표시할 IKE SA도 없으므로 두 목록이 동시에 비어 있을 수 있습니다.

이 순서가 로그를 읽기 쉽게 만듭니다. 먼저 acquisition이 오고, 그다음 IKE_SA_INIT과 IKE_AUTH, 그다음 CHILD SA입니다. 로그가 acquisition 직후 끝나면 트리거는 동작한 것입니다. 협상이 실패했고, 다음 질문은 trap이 아니라 자격 증명, 제안, 도달 가능성에 관한 것입니다.

Linux 커널 백엔드에서는 어떤 SA도 존재하기 전에 정책을 볼 수 있습니다. 다음을 실행하고 ip xfrm policy 방향 out과 연결을 가리키는 템플릿이 있는 선택자를 찾으세요. 그 항목이 온디맨드 상태이며, 그 존재가 가장 먼저 확인할 것입니다.

start_action은 무엇이든 기다릴지 결정합니다

각 child의 swanctl.conf 에는 start_action. start 가 구성이 로드될 때 시작하고, trap 는 정책을 설치하고 기다리며, none 는 시작을 다른 것에 맡깁니다. 오직 trap 만이 위에 설명된 “ping하면 올라온다” 동작을 만듭니다.

children {
    office-lan {
        local_ts = 192.168.50.0/24
        remote_ts = 192.168.70.0/24
        start_action = trap
    }
}

두 트래픽 선택자는 무엇이 흥미로운지 정의합니다이며, 이 접두사 밖 호스트의 패킷은 trap을 발동하지 않고 평소대로 라우팅됩니다. 트리거를 더 민감하게 하려고 선택자를 넓히면 터널이 보호한다고 주장하는 범위도 넓어지므로, 실제로 암호화하려는 트래픽에서 도출하세요.

swanctl.conf 참조 는 허용되는 값과 함께 SA가 존재한 뒤의 동작을 규정하는 별도의 close 및 DPD 작업을 나열합니다.

트리거가 실제로 발동했는지 알아보세요

먼저 swanctl --list-conns 로 child가 의도한 작업으로 로드되었는지 확인합니다. 그다음 local_ts 안의 호스트에서 remote_ts 안의 주소로 패킷 하나를 보내고 swanctl --list-sas 를 지켜보세요. 출력이 바뀌지 않으면 acquisition이 데몬에 도달하지 않은 것입니다.

조용한 trap의 흔한 이유 두 가지: 패킷이 정책에 닿기 전에 source-NAT되어 더 이상 local_ts 와 일치하지 않거나, 구문 또는 자격 증명 오류로 연결이 아예 로드되지 않은 경우입니다. 선택자를 건드리기 전에 swanctl --load-all 를 다시 실행해 출력을 읽으세요. 로드에 실패한 연결은 정책을 설치하지 않으므로 트래픽이 발동할 것이 없습니다.

방향도 중요합니다. 나가는 트래픽용으로 설치된 trap은 들어오는 패킷에서 시작되지 않습니다. 원격 측이 터널을 올려야 한다면 자체 trap이 필요하거나, 이쪽에 start.

첫 패킷을 기다리는 것이 항상 옳은 거래는 아닙니다

대화형 세션은 설정 비용을 체감합니다. 첫 요청이 IKE 교환과 CHILD 협상 비용을 치르고, 기한이 짧은 클라이언트는 SA가 생기기 전에 포기할 수 있습니다. 사전 start 는 그 첫 패킷 지연을 없앱니다. 다만 오지 않을 수도 있는 트래픽을 위해 터널을 올려 둡니다.

세 가지 사실이 선택을 결정합니다. 경로가 얼마나 자주 쓰이는지, 첫 요청의 기한이 촉박한지, 부팅 시 피어에 도달할 수 있는지입니다. 간헐적 배치 트래픽과 부팅 시 오프라인일 수 있는 피어는 둘 다 trap 를 지지합니다. 지연에 민감한 클라이언트와 항상 도달 가능한 피어는 start 를 지지합니다. 양쪽 모두 시작할 수 있다면 중복 협상을 피하도록 누가 트리거를 가질지 합의하세요.

설치된 정책도 유출 방지 보장은 아닙니다. 요구 사항이 fail-closed라면 방화벽이 SA 없는 트래픽을 버려야 하며, 그 규칙은 child 정의 밖에 있습니다.

다음 논쟁을 끝낼 세 줄을 기록하세요

선택자, 시작 시 동작, 그리고 SA 없이 정책이 존재함을 보여 주는 명령 출력을 적어 두세요. 그 세 줄이 다음에 누군가 터널이 다운이라고 보고할 때 “온디맨드이며 대기 중”과 “로드되지 않음”을 구분합니다. 기록하는 데 일 분이 걸립니다. 그것이 없으면 같은 조사가 처음부터 다시 시작됩니다.

정말로 선택자 안에 있는 호스트에서 시험하세요. 라우터 자체에서 보내는 ping은 다른 경로를 따르는 경우가 많고, 그 뒤 서브넷을 보호하는 정책에 대해 아무것도 증명하지 못합니다.