AWS VPN PSK 순환: 어느 터널이 끊기고, 언제 끊기는가

양쪽 끝이 사전 공유 키에 대해 합의하지 못하는 순간 터널이 끊기고, 양쪽이 새 값을 실을 때까지 내려간 채로 남습니다. 이 부분은 예상된 일입니다: AWS는 이 변경을 선택된 터널의 중단으로 취급하며, 키가 다른 동안 피어는 IKE를 끝내지 않습니다. 사람들을 놀라게 하는 것은 후반부입니다. 다른 터널은 그것이 트래픽을 실을 수 있는지 확인하지 않았다면 스스로 트래픽을 떠맡지 않습니다. 이 순서로 순환하면 중단은 한 터널 안에 머뭅니다.

키가 바뀌면 실제로 무슨 일이 일어나는가

ModifyVpnTunnelOptions는 외부 IP 주소로 식별되는 한 터널의 옵션을 다시 씁니다. 터널은 허물어지고 다시 만들어지므로 IKE와 IPsec은 새 키로 처음부터 협상합니다. AWS는 중단이 몇 분간 이어질 수 있다고 밝히며, 이는 라우팅 프로토콜이 알아차리기에 충분히 깁니다. 같은 연결의 다른 터널은 이 호출의 영향을 받지 않습니다.

무언가를 보내기 전에 알아 둘 두 번째 영향이 있습니다. 변경 작업은 터널 옵션 전체를 받으므로 생략한 필드는 기본값으로 다시 기록됩니다. 1단계나 2단계 수명, 또는 데드 피어 감지 설정을 조정했다면 현재 값을 같은 요청에 전달하거나 나중에 복원할 계획을 세우십시오.

먼저 현재 값을 읽고, 그다음 필드 하나를 바꾸십시오. 그 순서가 이 작업의 전부입니다.

먼저 AWS 터널을 올바른 피어와 맞추십시오

콘솔은 터널에 순서대로 레이블을 붙이지만, 장비는 그 레이블을 쓰지 않습니다. 외부 IP 주소로 터널을 식별하고 고객 게이트웨이의 피어 절과 맞추십시오. 로컬 구성의 터널 1은 AWS가 터널 1이라고 부르는 터널을 편집하고 있다는 증거가 아닙니다.

연결 자체에서 시작하면, 연결은 두 터널과 각 터널이 지금 보유한 키를 나열합니다:

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query "VpnConnections[0].Options.TunnelOptions[].[OutsideIpAddress,PreSharedKey]"

돌아오는 키가 지금 사용 중인 키이므로, 무언가를 바꾸기 전에 피어 구성과 비교하십시오. 이미 존재하는 불일치는 애초에 안정된 적 없는 터널을 설명합니다.

먼저 다른 터널이 트래픽을 실어 나르게 하십시오

한 연결에 터널이 둘 있다는 것은 장비가 둘 다 구성했다거나, 둘 다 필요한 프리픽스를 광고한다거나, 둘 사이로 트래픽이 흐른다는 것을 증명하지 않습니다. 대체 터널의 협상, 그 경로, 양방향의 실제 애플리케이션 흐름을 확인하십시오. BGP에서는 살아 있는 인접 관계가 유용한 증거이지만 프리픽스를 확인하는 것과 같지는 않습니다. 정적 라우팅에서는 게이트웨이가 경로를 어떻게 고르고 선호 경로가 사라질 때 무엇을 하는지 확인하십시오.

대체 터널이 작업 부하를 실을 수 없다면 키를 건드리기 전에 중단 일정을 잡거나 대체 터널을 수리하십시오. 콘솔 페이지의 상태등은 무중단 서비스의 약속이 아닙니다.

터널 하나를 순환한 다음 실제 트래픽으로 검증하십시오

대체 경로가 증명되면 절차는 짧습니다. 터널 주소, 그 피어, 비밀이 아닌 설정을 기록하고, 곧 끊을 터널에 의존하지 않는 관리 경로를 게이트웨이에 유지하십시오.

1. 선택한 외부 주소에 대해 고객 게이트웨이 피어를 업데이트하거나, API 호출 몇 초 뒤에 적용되도록 변경을 준비하십시오.
2. 새 키와 현재 수명 및 DPD 값을 함께 담아 변경 호출을 보내십시오.
3. IKE와 IPsec이 돌아오기를 기다린 다음 경로와 필요한 프리픽스를 확인하십시오.
4. 대표적인 애플리케이션 흐름을 그 터널로 보내고 양방향을 지켜보십시오.

양쪽이 합의하지 못하고 AWS가 변경을 적용하는 동안 터널은 쓸 수 없으므로, 피어 업데이트는 점심 뒤가 아니라 즉시 이어져야 합니다. 변경된 터널이 실제 트래픽을 실은 뒤에야 다른 터널에서 절차를 반복하십시오.

첫 터널 뒤에 복구나 라우팅이 여전히 불확실하면 멈추십시오. 반쯤 작동하는 터널 둘은 작동한다고 아는 하나보다 나쁩니다.

복구가 막히면 IKE 쪽을 읽으십시오

양쪽 끝이 새 키를 가진 뒤에도 내려간 채로 남는 터널은 보통 순환이 드러낸 정책 불일치이며, 순환이 만든 것이 아닙니다. 제안, 피어가 보내는 신원, 트래픽 선택자는 모두 AWS 쪽과 일치해야 하며, 이미 성립된 터널에서 살아남은 값도 새 협상 중에는 거부될 수 있습니다. 키를 두 번째로 바꾸기 전에 협상 상태와 그에 붙은 메시지를 읽으십시오.

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query "VpnConnections[0].VgwTelemetry[].[OutsideIpAddress,Status,StatusMessage]"

변경을 되돌려야 한다면 예전에 작동했다는 이유만으로 옛 키를 복원하지 마십시오. 손상된 키는 손상된 것으로 취급하고 대신 협상을 고치십시오. 두 터널을 검증하고, 각 피어가 어떤 값을 보유하는지 기록하도록 비밀 목록을 갱신한 상태로 마무리하고, AWS 터널 옵션 문서를 런북 옆에 두십시오.