AWS가 Site-to-Site VPN 터널을 시작하게 하는 방법
시작 작업과 DPD 타임아웃 작업은 서로 다른 질문에 답합니다. AWS가 시작하게 하는 작업을 설정한 다음 피어 주소와 앱의 경로를 확인하세요.
기본적으로 AWS Site-to-Site VPN은 customer gateway가 협상을 시작하기를 기다립니다. 그 기본값은 설정일 뿐 법칙이 아니며, 설정 이름은 Startup action입니다. 그것을 건드리기 전에 늘 뒤섞이는 두 질문을 분리하세요. 터널을 누가 세우는가, 그리고 관심 있는 패킷이 그 터널을 지나는 경로를 가지고 있는가입니다. 터널 옵션에 있는 것은 첫 번째뿐입니다.
시작 작업과 DPD 타임아웃 작업을 분리하세요
터널당 두 옵션은 서로 다른 두 이벤트를 제어하며, 하나를 설정해도 다른 하나에 대해서는 아무것도 말하지 않습니다.
| Event | Option | Useful values |
|---|---|---|
| A new or modified VPN connection needs a tunnel | Startup action | add waits for the peer; start asks AWS to initiate |
| Dead peer detection times out | DPD timeout action | clear ends the session, restart reinitiates, none does nothing |
AWS가 새 터널이나 변경된 터널을 세워야 한다면 다음을 선택하세요: start. DPD 타임아웃 후 협상도 다시 시작해야 한다면 그 이벤트에 대해 별도로 restart 를 구성하세요. 어느 옵션도 앱의 재시도 정책이 아니고, 어느 것도 키 갱신 간격이 아닙니다. DPD는 피어가 살아 있는지 확인하고, 키 갱신은 살아 있는 터널에서 security associations를 교체합니다.
터널이 여전히 up을 보고하는데 타임아웃되는 앱은 데이터 경로 문제를 겪고 있습니다. DPD 타이머를 줄여도 해결되지 않으며, 나중에 설명해야 할 잡음이 늘어날 수 있습니다.
AWS에 협상을 보낼 곳이 있는지 확인하세요
AWS 측 시작은 IKEv2에서만 가능하며, AWS는 제안을 어디로 보낼지 알기 위해 customer gateway의 공인 주소가 필요합니다. 가장 아픈 경우는 주소 없이 만든 인증서 인증 customer gateway 리소스입니다. AWS 문서는 주소가 있는 새 customer gateway 리소스를 만들고 그다음 VPN 연결이 그것을 가리키도록 변경하는 절차를 설명합니다.
인증서는 피어가 누구인지 증명합니다. 피어가 어디에 있는지는 AWS에 알려 주지 않으며, 이 둘은 서로 다른 요구 사항입니다. 그래서 해결책은 새 인증서가 아니라 새 customer gateway 리소스입니다. 인증서를 바꿔도 AWS에는 같은 누락된 목적지가 남습니다.
customer gateway가 NAT 뒤에 있다면, AWS에는 구성된 responder identity도 필요합니다. IDr피어의 ID가 장치가 기대하는 것과 일치하도록 하기 위해서입니다. 방금 바꾼 옵션을 탓하기 전에 그 값과 IKE 트래픽을 통과시키는 방화벽 경로를 확인하세요. start 를 선택해도 도달할 수 없거나 잘못 식별된 피어가 제안을 받아들이게 할 수는 없습니다.
변경을 터널 하나에 적용하고 중단을 예상하세요
VPN 연결에는 독립적인 옵션을 가진 터널이 둘 있으므로 외부 주소로 어느 것을 편집하는지 확인하세요. AWS는 한 번에 하나의 터널만 수정할 수 있으며, 선택한 터널을 통한 연결은 몇 분 동안 끊길 수 있습니다.
- Site-to-Site VPN 연결을 선택하고 Modify VPN tunnel options를 엽니다.
- 외부 IP 주소로 터널을 고르고 그 IKE 버전과 customer gateway 리소스를 확인합니다.
- 실제로 원하는 시작 및 DPD 작업을 설정한 다음 직접 통제하는 시간대에 저장합니다.
- 변경한 터널이 설정되는지 확인하고, 다음 변경 전에 다른 터널과 라우팅을 확인합니다.
유지 보수 전에 한 가지 동작을 살펴볼 만합니다. AWS 시작이 켜져 있으면 타임아웃이 없습니다. AWS는 터널이 올라올 때까지 계속 시도하고, customer gateway가 delete-SA 메시지를 보내면 다시 시작합니다. 피어를 일부러 내리면 AWS는 계속 두드리며, 피어의 로그에 그것이 남습니다.
터널 상태만이 아니라 앱의 경로를 검증하세요
up을 보고하는 터널은 동작하는 요청과 같지 않습니다. VPC에 연결된 Lambda 함수에는 여전히 고객 프리픽스로 가는 subnet 경로, 트래픽을 허용하는 security group과 network ACL 규칙, 올바른 주소를 돌려주는 이름 확인, 그리고 고객 측의 반환 경로가 필요합니다.
앱의 컨텍스트에서 실제 요청으로 한 번 시험하고, 실패하면 flow logs를 읽으세요. AWS 시작이 꺼져 있고 유휴 터널이 패킷을 필요로 할 때 keepalive 트래픽은 정당한 선택이지만, 이름 붙일 수 있는 모니터링 결정이어야 하며 함수에 볼트로 고정된 설명 없는 ping 루프여서는 안 됩니다.
먼저 터널을 누가 세우는지 고르고, 그다음 남은 실패를 그 계층에서 진단하세요. AWS 시작 문서 는 주소, ID, 재시도 요구 사항을 콘솔 힌트보다 자세히 다룹니다.