EC2의 strongSwan: VPC가 워크로드를 라우팅하게 하기

터널은 올라와 있고 게이트웨이 인스턴스는 원격 네트워크로 ping을 보낼 수 있는데, 바로 옆의 애플리케이션 인스턴스는 아무것도 닿지 않는다. 고장 난 것은 없다. 성공한 테스트는 VPN 호스트에서 시작되었고, 그 호스트가 같은 IPsec 관계로 다른 소스 주소를 실어 나를 수 있는지는 한 번도 묻지 않았다. 이 런북은 각 실패가 보이도록 유지하는 순서로 그 간극을 네 단계로 닫는다.

먼저 네 주소를 적어 둔다

아래 각 단계는 이 주소를 참조하므로, 라우팅 테이블을 건드리기 전에 자신의 계정에 맞게 채워 둔다.

VPC:             10.60.0.0/16
Gateway subnet:  10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network:  10.90.0.0/24

예제는 승인되어 동작하는 정책 기반 IPsec 연결과 소스를 보존하는 흐름을 전제한다. 이것은 할당된 주소 하나를 빌리는 NAT 원격 접속 클라이언트가 아니며, 그 차이가 셀렉터를 바꿔야 하는지를 결정한다.

1단계: 워크로드 서브넷에 경로를 준다

워크로드 서브넷에 실제로 연결된 라우팅 테이블에는 원격 프리픽스로 가는 경로가 게이트웨이의 네트워크 인터페이스를 가리켜야 한다. 인스턴스 안에 설치한 게스트 경로는 그 AWS 라우팅 테이블의 항목이 아니며, 아무리 strongSwan을 설정해도 만들어지지 않는다.

AWS의 어플라이언스 경유 라우팅 지침은 네트워크 인터페이스 유형 대상과 전달하는 인스턴스의 소스/대상 확인 요구 사항을 설명한다. 그 확인 변경은 게이트웨이 역할로 한정하고, 일반 애플리케이션 인스턴스는 그대로 둔다.

승인된 네트워크 하나를 위해 VPC의 로컬 경로나 기존 항목을 모두 바꾸지 않는다. 무엇이 연결되어 있고 활성인지 확인하는 것이지, 아무도 쓰지 않는 라우팅 테이블에 대해 콘솔 화면이 무엇을 보여 주는지가 아니다. 비슷해 보이는 두 테이블도 연결이 다를 수 있다. 중요한 것은 워크로드 서브넷이 연결된 테이블이다.

2단계: 게스트에서 전달을 켠다

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

커널은 전달해야 하고 호스트 방화벽은 통과를 허용해야 한다. 모든 것을 허용하는 대신 워크로드와 원격 프리픽스에 대해 의도한 전달 규칙을 추가하고, 게이트웨이 서브넷이 자체 트래픽에 쓸 수 있는 전송 경로를 유지하는지 확인한다.

이 단계가 보통 걸리는 곳은 보안 그룹이다. 중간 장치는 인스턴스 간 직접 통신의 보안 그룹 참조 동작을 물려받지 않으므로, 관리형 Client VPN 예제에서 복사한 규칙은 결코 일치하지 않을 수 있다. 실제 경로에서 양방향으로 보안 그룹과 서브넷 ACL을 확인한다.

3단계: 셀렉터를 실제 소스까지 넓힌다

AWS 쪽에서 10.60.1.10/32만 덮는 정책은 10.60.2.20를 덮지 않은 채 게이트웨이에서 시작된 성공을 설명한다. 원격 목적지로 가는 경로는 트래픽 셀렉터를 넓히지 않으며, 그것이 같은 놀라움의 후반부다.

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

합의된 설계가 VPC 전체를 보호한다면 양쪽이 10.60.0.0/16와 10.90.0.0/24를 받아들여야 하고, 워크로드 하나만 보호한다면 그 좁은 프리픽스를 의도적으로 쓴다. 어느 경우든 설치된 CHILD-SA 정책을 확인해야 한다. 당신이 편집한 구성과 다른 방식으로 좁힌 상대는 같은 합의가 아니다.

원격 사이트도 보존된 VPC 소스에 대한 응답을 의도한 IPsec 게이트웨이로 되돌려 라우팅해야 하고, 다른 소스 NAT 규칙이 있는 곳에서는 보호 트래픽에 대해 지원되는 NAT 예외를 유지한다. 승인되지 않은 워크로드를 허용된 호스트 주소로 변환하는 것은 다른 아이덴티티 계약이며, 원한 접근으로 가는 지름길이 아니다.

4단계: 검증하고, 필요하면 되돌린다

워크로드 자체에서 새로 허용된 애플리케이션 작업으로 시험하고, 제외되어야 할 목적지로 반복한다. 원격 서비스가 보는 소스 주소와 그것이 쓰는 반환 경로를 기록한다. 게이트웨이 ping이나 녹색 IKE 상태는 그 테스트가 아니다.

게이트웨이가 동작하는데도 워크로드가 계속 실패한다면 단계를 순서대로 되짚는다: 셀렉터, 다음으로 전달과 보안 그룹, 다음으로 연결된 라우팅 테이블이다. 각각 증상이 다르며, 추측은 실제로 틀린 하나를 건너뛴다.

되돌리기는 같은 순서를 뒤집는다. 워크로드 서브넷의 경로는 이전 셀렉터를 복원한 뒤에 마지막으로 제거해야 소스를 더 이상 보호하지 않는 게이트웨이를 가리키는 서브넷을 남기지 않는다. 이 계약이 성립할 때 셀프 호스팅은 게이트웨이 호스트보다 많은 것을 감당할 수 있고, AWS 관리형 Site-to-Site VPN은 strongSwan이 고객 게이트웨이 쪽에 놓일 수 있는 다른 운영 모델이다.