IKEv2 SA는 올라갔지만 자식 SA가 없습니다: 교환을 읽으십시오
인증이 끝나도 자식 SA 협상이 실패할 수 있습니다. 경로나 카운터를 보기 전에 자식 SA 생성 교환, 그다음 제안과 선택자를 읽으십시오.
IKE는 터널이 올라갔다고 하고 자식 SA는 없다고 하는데, 두 진술은 동시에 참일 수 있습니다. 확립된 제어 관계는 데이터 연결이 아니며, 두 객체는 수명과 협상과 실패 방식이 따로 있습니다. 첫 번째를 연결성으로 보고하는 것이 바로 티켓이 마침내 터널은 올라갔지만 아무것도 동작하지 않는다고 주장하게 되는 경로입니다. 연결의 요약 레이블이 아니라 연결 목록을 읽으십시오, 그 목록만이 빠진 객체를 보여 주는 유일한 곳입니다. 다음은 그 목록이 의미를 갖는 순서입니다.
두 연결, 두 가지 일
IKE SA는 제어 채널, 즉 식별자와 키, 그리고 제어 교환 자체를 위한 제안을 나릅니다. 자식 SA는 ESP 보호를 나르며, 자체 알고리즘과 자체 트래픽 선택자를 가집니다. 인증과 자식 SA 생성은 보통 함께 가는데, 첫 자식 SA가 IKE_AUTH 안에서 협상되기 때문이며, 바로 그 묶음이 사람들을 이 분리에 놀라게 합니다.
이것은 앞으로 만나게 될 두 가지 실패 형태도 설명합니다. 초기 교환에서 거부된 자식 SA는 보통 IKE SA까지 함께 내리므로, 확립된 제어 채널을 전혀 볼 수 없습니다. IKE SA가 홀로 남는 경우는 오히려 첫 자식 SA가 성공했고 이후의 자식 SA 생성 시도가 실패했음을 뜻하는 경우가 많으며, 예를 들어 키 갱신 때입니다. 타임스탬프는 어떤 구성 검토보다 빠르게 그런 사례를 갈라냅니다.
어느 계층이 거부했나
자식 SA가 거부되면 알림은 계층을 지목합니다. 제안 거부는 양측이 알고리즘에 합의하지 못했다는 뜻이며, 흔히 한쪽이 다른 완전 전방 비밀성 그룹이나 상대가 받아들이지 않을 암호를 요구하기 때문입니다. 선택자 거부는 트래픽 집합이 그대로 거부되었다는 뜻이고, 이는 암호가 아니라 범위의 문제입니다.
때로는 자식 SA가 없는 것이 설계입니다. 자식이 없는 IKE SA는 정의된 확장으로, 데이터 연결을 요청 시에 만들어야 하는 상황에서 쓰이므로 없음이 정상이고 일치하는 트래픽이 오면 자식 SA가 나타납니다. IKEv2에 관한 strongSwan 노트 요청 시 방식과 첫 사례를 결정하는 제안 설정을 모두 다룹니다.
장애를 진단하기 전에 요청 시 또는 트랩 구성이 있는지 확인하십시오. 자식 SA가 지연 생성된다면 유휴 상태에서 자식 SA가 없는 것이 기대 상태이며, 진짜 시험은 트래픽이 하나를 올리는지입니다. 그 시험은 지연 설계를 조용한 실패와도 구분하는데, 생성이 실패하면 트리거는 단지 유휴가 아니라 응답 없이 남습니다.
그다음 데이터 경로를 물으십시오
자식 SA가 있으면 다음 질문에는 카운터가 답합니다. ip -s xfrm state 연결별 패킷과 바이트 수를 보고하며, 트래픽을 만들면서 아무것도 나르지 않는 자식 SA는 빠진 연결이 아니라 일치나 라우팅을 가리킵니다. swanctl --list-sas 그 카운터 옆에 자식 SA의 선택자를 인쇄하며, 패킷이 허용된 집합 안에 있음을 확인해 줍니다.
인증 성공과 자식 SA 교환 실패는 보고서에서 분리해 두십시오. 인증이 실패했다고 적은 보고서는 다음 엔지니어를 인증서 저장소로 보내지만, 정확한 문장은 훨씬 짧고 IKE SA는 올라갔으며 이 흐름의 자식 SA는 결코 허용되지 않았습니다.
두 끝을 맞추십시오
직접 운영하는 서버라면 한 시간 차이의 재접속 시도 두 번을 비교하는 대신 같은 교환의 클라이언트와 게이트웨이 로그를 가져오십시오. 알림은 양쪽에서 일치해야 하며, 일치하지 않는 곳이 있다면 설정이 잘못된 쪽을 찾은 것입니다.
자식 SA 협상을 고친 다음 의도한 선택자 안의 트래픽으로 다시 시험하십시오. 유휴 상태에서 갱신된 연결 목록이 수정 전후에 같아 보일 수 있으므로, 빠진 객체가 이제 있다는 것을 증명하는 시험은 이것뿐입니다.