IKEv2는 한 번의 핸드셰이크가 아니다: IKE SA, 인증, 그다음 CHILD SA
게이트웨이의 응답은 도달 가능성을 증명할 뿐 신원을 증명하지 않는다. IKE_SA_INIT, IKE_AUTH, 첫 CHILD SA를 따라가고 트래픽이 흐르기 전에 무엇이 참이어야 하는지 확인한다.
IKEv2 연결이 트래픽이 암호화되며 끝나는 한 번의 교환이라고 생각할 수 있다. 실제로는 적어도 두 번이고, 첫 번째는 아무도 인증하지 않는다. 피어는 제어 메시지로 시작해 암호 매개변수에 합의하고 신원을 증명한 뒤에야 응용 프로그램 패킷을 나르는 상태를 협상한다. 이 순서가, 게이트웨이는 응답하고 클라이언트는 연결됨을 표시하는데 사설 응용 프로그램은 여전히 시간 초과가 나는 불일치를 설명한다. 각 단계가 실제로 하는 일과 그 뒤에 무엇이 참이어야 하는지 살펴본다.
오해: 게이트웨이가 응답하면 연결된 것이다
첫 메시지에 대한 응답은 엔드포인트가 도달 가능하고 대화할 의사가 있음을 증명한다. 계정이 승인되었는지, 인증서 체인이 검증되었는지, 어떤 데이터 정책이 설치되었는지는 증명하지 않는다.
그런 실패는 나중에 일어나고 다른 증상을 낳는다. 인증서 거부나 EAP 실패는 첫 교환이 이미 성공한 뒤에 도착하므로, UDP 500으로의 ping과 클라이언트의 초록 아이콘은 아주 적은 것만 알려준다.
IKE_SA_INIT: 신원이 아니라 매개변수에 합의한다
첫 교환은 암호화와 무결성 알고리즘, 의사 난수 함수, Diffie-Hellman 그룹 등 IKE 보안 연관을 위한 제안을 나른다. 피어는 nonce도 교환하고, 각 측은 그 값들이 만드는 공유 비밀에서 IKE SA의 키 자료를 유도한다. 이 교환에는 상대가 누구인지 확립하는 것이 없다. 양측이 같은 키를 계산할 수 있고 하나의 제안에 합의한다는 점만 확립한다. 어떤 제안도 마음에 들지 않는 응답자는 여기서 교환을 거부하므로, 버전이나 알고리즘 불일치는 서버가 죽은 것처럼 보인다.
이 시점에 만들어진 IKE SA는 이후의 모든 관리 교환을 보호한다. 그것이 그 역할이고, 당신의 패킷을 보호하는 것과는 다른 역할이다.
IKE_AUTH: 신원을 증명하고 첫 CHILD SA를 만든다
두 번째 교환은 신원을 나른다. 인증서를 쓰면 각 피어가 자기 개인 키로 서명하고 상대가 검증해야 하는 체인을 제시한다; EAP를 쓰면 응답자가 선택한 방법으로 개시자에게 도전한다. 잘못된 서버 이름, 만료된 인증서, 거부된 비밀번호가 마침내 여기서 드러난다.
보통 IKE_AUTH는 첫 CHILD SA도 협상하므로 데이터 보호가 같은 왕복에서 합의된다. 개시자가 트래픽 선택자를 제안하고 응답자가 좁히거나 거부하며, 데이터 경로의 키는 IKE SA에서 유도된다. 즉 한 번의 교환이 신원과 정책이라는 아주 다른 두 지점에서 실패할 수 있다. 일반적인 핸드셰이크 실패가 아니라 알림 페이로드나 오류를 읽어야 하는데, 하나의 해결책은 인증서이고 다른 하나는 서브넷 불일치이기 때문이다.
두 SA, 두 역할
| 연관 | 보호 대상 | 수명 동작 |
|---|---|---|
| IKE SA | 관리 교환: 키 재생성, 삭제, 구성 페이로드 | 자체 일정에 따라 재생성되며 데이터 경로는 그 변경을 견딜 수 있다 |
| CHILD SA | 트래픽 선택자와 일치하는 응용 트래픽 | 독립적으로 재생성되며 흔히 더 자주 일어난다 |
둘을 분리하면 버그처럼 보이는 두 동작이 설명된다. 터널이 설정됨으로 표시되는 동안 백그라운드에서 키 재생성이 실패할 수 있고, 클라이언트가 연결을 끊지 않고 CHILD SA를 교체할 수 있다.
strongSwan에서는 IKEv2 구성 참조와 swanctl --list-sas가 두 계층을 모두 보여주고, ip xfrm state와 ip xfrm policy는 커널이 실제로 무엇을 설치했는지 보여준다. 두 뷰를 비교하는 것이 협상이 끝났는지 아니면 끝난 것처럼 보였는지 확인하는 가장 빠른 방법이다. 데몬이 커널에 상태가 없는 CHILD SA를 나열한다면 설치는 조용히 실패한 것이다. 커널이 데몬이 모르는 상태를 가지고 있다면 이전 시도의 잔여물을 보고 있는 것이다.
터널이 올라온 뒤에도 무엇이 참이어야 하는가
트래픽 선택자는 어떤 주소가 포함되는지 정의한다. 클라이언트가 한 서브넷을 제안하고 서버가 다른 서브넷을 기대하면, CHILD SA는 설치되지만 유용한 것을 나르지 않는다, 그리고 오류는 협상 문제가 아니라 라우팅 문제로 나타난다. 그다음 로컬 스택이 협력해야 하는데, 호스트가 라우팅하는 곳에서 포워딩이 켜져 있어야 하고, 터널을 향하는 경로가 있어야 하고, 캡슐 해제된 패킷을 허용하는 방화벽 규칙이 있어야 하며, 사설 이름이 관련되면 내부 리졸버가 있어야 한다. 각각은 따로 실패하고 어느 것도 IKE 데몬 재시작으로 고쳐지지 않는다.
진단하는 동안 로그를 보이게 두고, 초기 교환, 그다음 신원 검증, 해당되는 경우 사용자 인증, 그다음 CHILD 설치, 마지막으로 응용 트래픽을 확인하라. 멈추는 단계가 고쳐야 할 단계이고, 나중의 라우팅 실패는 이미 통과한 신원 검사를 완화할 이유가 결코 아니다.