Cloud VPN에서 Cisco ASA로: 제안 불일치 후 재구축

반대편에 Cisco ASA가 있는 Cloud VPN 터널의 NEGOTIATION_FAILURE는 거의 항상 제안이나 셀렉터의 불일치이며, 첫 번째로 유용한 사실은 어떤 편집으로도 고칠 수 없다는 것입니다. Cloud VPN은 터널 객체를 만들 때 IKE 제안을 고정합니다. 알고리즘을 그 자리에서 바꾸는 필드는 없으므로 복구는 삭제 후 기록된 시작점으로 다시 만드는 것입니다. 재구축으로 취급하면 작업은 추측으로 보내는 오후가 아니라 점검 목록이 됩니다.

무엇이든 지우기 전에 실패를 읽으십시오

협상 실패는 단계 문제이고 피어 로그는 보통 어느 단계인지 알려 줍니다. 1단계 실패는 양쪽 끝이 제안에 합의하지 못했거나 서로 인증하지 못했다는 뜻입니다. 2단계 실패는 터널은 올라왔지만 보호 셀렉터가 맞지 않았다는 뜻입니다. 서로 다른 복구이며, 누군가 설정을 만지기 전에 로그 줄을 뽑아 두는 편이 좋습니다.

이 실패는 몇 가지를 배제합니다. VPC 경로도, 터널 인터페이스의 방화벽 규칙도, 네트워크 내부의 이름 해석 결함도 아닙니다. 그것들을 쫓으면 결과를 바꿀 수 없는 자신감 있는 변경만 생기고, 최종 수정을 누구 몫으로 돌릴지 어려워집니다.

두 설정이 아직 존재할 때 기록하십시오

터널 삭제는 금방 끝나고 유일한 증거를 없앱니다. 그 전에 로컬과 원격 셀렉터, 피어 주소, 공유 비밀의 소유자, ASA의 crypto map 또는 IKEv2 프로필을 적어 두십시오. ASA는 두 가지 질문에 답합니다. 무엇이 설정되어 있는가, 지금 무엇이 올라와 있는가:

show running-config crypto ikev2
show crypto ikev2 sa
show crypto ipsec sa | include local ident|remote ident|status

Google 쪽에서는 콘솔 요약이 아니라 터널 객체를 읽으십시오. 피어 주소와 셀렉터 필드가 바로 정확히 재현해야 할 값입니다:

gcloud compute vpn-tunnels describe tunnel-to-asa --region europe-west1 \
  --format="yaml(peerIp,localTrafficSelector,remoteTrafficSelector,ikeVersion,sharedSecret)"

첫 삭제 전에 그 값을 티켓에 적으십시오. 아래 재구축이 되는 이유는 같은 객체를 의도한 차이 하나로 다시 만들 수 있기 때문입니다.

한쪽이 협상을 거부하는 알고리즘

Cloud VPN은 전통적인 피어처럼 IKEv1 알고리즘 범위에서 고르지 않습니다. 기대하는 피어 설정은 고정입니다. 암호화에 aes-cbc-128, 무결성과 PRF 모두에 sha1-96, Diffie-Hellman 그룹 2, 1단계에 36,600초, 2단계에 10,800초입니다. ASA 정책은 정확히 그 집합을 제공해야 합니다. ASA에 두 번째 제안이 있어도 맞는 것이 목록에 있으면 해롭지 않습니다.

IKEv2는 양쪽에 더 많은 여지를 주지만 규칙의 형태는 같습니다. PFS를 켜고 터널이 지원하는 DH 그룹을 고르고, 불일치가 분명해질 만큼 제안 목록을 짧게 유지하십시오. Cloud VPN에서 ASA 피어는 정적 라우팅도 뜻하므로 보호 프리픽스는 BGP에 맡기지 말고 계획해서 나열해야 합니다.

다른 벤더 템플릿에서 복사한 수명은 여기서 흔한 잘못된 길입니다. Google은 이 값을 필수 피어 설정으로 공개하므로 그대로 설정하십시오. 더 짧은 값이 ASA가 원하는 값까지 위로 협상되지는 않습니다.

삭제하고 다시 만들고 오래된 상태를 지우십시오

게이트웨이가 아니라 터널을 삭제하고 Cloud VPN이 대체물에 붙이는 이름을 적어 두십시오. 이름은 재사용되지 않고 부여되기 때문입니다. 기록한 값과 같은 피어 주소로 다시 만들고, 맞는 제안을 ASA 정책 목록에 추가하십시오.

ASA 변경 후 결과를 읽기 전에 보안 연결을 지우십시오. ASA는 현재 SA가 만료될 때까지 오래된 정책을 계속 제공할 수 있으므로, 올바른 설정이 옛 수명 내내 고장 난 것처럼 보이고 관찰자는 재구축이 시작도 하지 않았는데 실패했다고 결론 내립니다:

clear crypto ikev2 sa
clear crypto ipsec sa

2단계를 보기 전에 1단계가 올라오는지 확인하십시오. 1단계가 내려가 있는 동안은 제안이나 사전 공유 키가 틀린 것이며, 셀렉터 작업으로는 바뀌지 않습니다.

셀렉터는 거울처럼 맞추고, 마지막은 카운터가 결정합니다

2단계는 보호할 주소에 양쪽 끝이 합의할 때만 동작하며, 그 합의는 공유가 아니라 거울입니다. Google의 로컬 셀렉터는 ASA가 원격이라고 부르는 셀렉터와 맞아야 하고, Google의 원격 셀렉터는 ASA가 로컬이라고 부르는 것과 맞아야 합니다. 한쪽이 0.0.0.0/0이고 다른 쪽이 단일 서브넷인 터널은 1단계를 통과한 뒤 같은 주요 오류로 2단계에서 실패합니다. 어느 쪽도 상대의 목록을 넓힐 수 없습니다.

정책 기반 셀렉터라면 모든 프리픽스 쌍을 나열하고 목록을 티켓에 남기십시오. 나중에 현장에서 추가한 서브넷은 양쪽 끝을 편집해야 합니다. ASA의 새 경로는 셀렉터를 넓히지 않으므로, 결과는 터널이 올라와 있어도 첫날 존재한 프리픽스에만 트래픽이 통하는 상태가 됩니다.

호스트 간 흐름 하나로 마무리하고 양쪽의 바이트 카운터를 읽으십시오. ASA에서 늘고 Google에서 평평한 카운터는 보통 응답이 다른 인터페이스로 나가거나 셀렉터가 돌아오는 프리픽스를 덮지 못한다는 뜻입니다. 알고리즘, 수명, 셀렉터, 새 터널 이름을 기록하십시오. 다음 제안 변경 때 이 재구축을 반복하게 되고, 그 값들이 일을 짧게 만듭니다.