strongSwan에서 AWS Site-to-Site로: Child SA가 아무것도 선택하지 않는 이유

IKE 터널이 올라가 있어도 자식 연결이 서브넷을 제외하면 트래픽은 지나가지 않습니다. 먼저 AWS의 로컬 및 원격 CIDR을 leftsubnet, rightsubnet과 비교하십시오.

콘솔은 up을 표시하고 strongSwan은 설정된 IKE 연결을 보고하지만 패킷은 여전히 도착하지 않습니다. 다음에 비교할 것은 미리 공유한 키가 아니라 각 측이 터널이 보호한다고 믿는 프리픽스 쌍입니다. 처음 두 가지가 터널이 트래픽을 실어 나를 수 있는지 결정하므로, 아래 점검을 순서대로 진행하십시오.

AWS의 이름을 strongSwan 용어로 옮기십시오

AWS는 고객 측에서 연결을 설명하며, 고객 게이트웨이 주소와 로컬 CIDR은 여러분 쪽에 속하고 원격 CIDR은 VPC에 속합니다. strongSwan은 양 끝을 left와 right라고 부르며 여러분의 프리픽스는 leftsubnet에, VPC 프리픽스는 rightsubnet에 들어갑니다. 한 쌍을 뒤집으면 잘못된 트래픽을 협상하고 선택하는 터널이 됩니다.

AWS가 연결을 위해 생성한 구성을 내려받아 터널 주소와 프리픽스를 포함해 그 연결만의 기준으로 삼으십시오. 생성할 때 두 CIDR 필드를 비워 두면 서비스는 각 측에서 기본값 0.0.0.0/0을 사용합니다. 좁은 프리픽스로 설정된 라우터는 그러면 결코 일치하지 않으므로 필드를 채우거나 선택자를 의도적으로 넓히십시오.

여기서의 불일치는 라우팅 실패처럼 보이지만 그렇지 않습니다.

AWS가 실제로 보는 주소를 고정하십시오

NAT 뒤의 라우터는 반대편이 전혀 알지 못한 인터페이스에서 IKE를 보낼 수 있습니다. AWS에 기록된 게이트웨이 주소는 AWS가 회선에서 관찰하는 주소여야 하며 라우터는 기본 경로를 따르는 대신 같은 로컬 주소에 고정되어야 합니다.

conn %default
    local_addrs = 203.0.113.10

strongSwan에서 local_addrs는 IKE의 원본 주소를 선택하고 오래된 OpenSwan 구성은 같은 개념을 left로 씁니다. 이전 라우터에서 남은 규칙이 조용히 버리므로, 공인 주소가 있는 인터페이스로 지정한 다음 NAT 장비 자체에서 UDP 500과 4500이 해당 호스트에 도달하는지 확인하십시오. 올바른 선택자 쌍이라도 원본 주소가 틀리면 실패하며 로그는 제안을 탓합니다. 그 오도 때문에 원본 주소에 별도의 점검이 필요합니다.

이전 라우터에 맞았던 규칙은 자주 남으므로 전달 규칙을 당연하게 여기지 말고 확인하십시오.

1단계와 2단계를 따로 다루십시오

AWS는 IKE와 ESP 옵션을 별도 목록으로 보여 줍니다. 두 목록이 독립적이므로 양측이 받아들이는 IKE 집합은 ESP 제안에 대해 아무것도 말하지 않습니다. 생성된 구성에서 둘 다 읽고 하나씩 비교하십시오.

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

구문은 구현 간에 이동하지 않습니다. OpenSwan에서 동작하는 쌍, 예를 들어 phase2alg=aes_gcm과 ike=aes256-sha1;modp1024은 strongSwan의 esp=와 ike= 형태로 옮겨야 하며 알고리즘 이름도 다릅니다. GCM은 암호화하면서 인증하므로 SHA와 짝지은 CBC 집합과 달리 별도의 무결성 변환이 필요 없습니다. 한 데몬에서 다른 데몬으로 번역 없이 붙여 넣은 2단계 행은 선택자 불일치처럼 읽히는 거부를 만듭니다.

터널 표시가 아니라 자식 연결을 확인하십시오

연결은 로드되지만 자식 연결이 올라오지 않으면 제안이나 선택자가 거부된 것입니다. 자식이 올라오는데 그 선택자가 여러분의 프리픽스를 제외하면 패킷은 터널에 도달하기 전에 필터링됩니다. 콘솔 표시는 IKE 계층만 다루므로 둘 중 무엇이 일어났는지 알려 줄 수 없습니다.

ipsec statusall

자식 보안 연결을 찾아 옆에 표시된 트래픽 선택자를 읽고 생성된 구성의 프리픽스와 비교하십시오.

로컬 프리픽스 내부의 호스트에서 VPC 프리픽스 내부의 호스트로 시험하고 반환 경로와 AWS 측의 보안 그룹이나 네트워크 ACL도 확인하십시오. 올바른 선택자라도 나중에 패킷이 버려지는 것을 막지는 못합니다.

선택자가 일치한 뒤에도 실패할 때

양측의 경로가 터널을 가리키는지 확인하고 다음으로 NAT 장비가 정책이 예상하지 않는 방식으로 트래픽을 다시 쓰지 않는지 확인하십시오. 정책 기반 터널은 패킷 주소를 대조하므로 정책 결정 후 적용되는 변환은 결과를 바꿉니다.

다른 제안을 바꾸기 전에 각 측에서 들어오는 패킷 하나와 나가는 패킷 하나를 기록하십시오.

티켓에 선택자, 1단계와 2단계 제안, 원본 주소를 기록하십시오. 이 네 가지 값이 전화 없이 대부분의 site-to-site 실패를 설명합니다.

관련 글