Google HA VPN para um router Cisco: planeie primeiro o recurso de par
Nomeie as duas interfaces Google, o recurso de par, o contrato IKEv2 e cada sessão BGP antes de configurar o router Cisco, e depois escolha um par ou dois.
A primeira decisão numa HA VPN de Cisco para Google não é qual perfil criptográfico usar, mas sim se um dispositivo local ou dois vão terminar os túneis. O gateway HA VPN da Google tem duas interfaces, e cada uma espera um túnel de par correspondente. Isso dá-lhe dois túneis quer tenha dois routers quer não, e a diferença é se uma única fonte de alimentação ou uma atualização de software pode derrubar todo o desenho.
A decisão é um dispositivo de par ou dois
Escolha o esquema com base em três condições: se pode aceitar um ponto de falha local, se ambas as interfaces de nuvem têm de ser usadas e quanta reconvergência as suas cargas de trabalho toleram. Se qualquer uma das três for um requisito rígido, dois dispositivos de par é a resposta honesta.
Decida isso antes de abrir uma consola, porque a resposta altera quantos túneis e sessões BGP a folha de trabalho tem de descrever.
Escreva a folha de trabalho antes de qualquer comando
A folha de trabalho tem cinco linhas, e cada uma precisa de um responsável:
| Row | What it records |
|---|---|
| Google side | Project, VPC, region, HA VPN gateway, and the external address of each interface |
| Peer side | The Cisco external addresses, plus the external peer VPN gateway resource that represents them |
| Tunnel pairs | Which peer interface maps to each Google interface, with IKE version, secret and crypto parameters |
| Routing | Cloud Router, local and remote AS numbers, and one inside BGP pair per tunnel |
| Workloads | Approved on-premises and VPC prefixes, and what firewall policy should permit between them |
O recurso de par externo descreve as suas interfaces dentro do Google Cloud, e criá-lo não configura o router Cisco. Essa assimetria surpreende quem espera que a consola de nuvem seja a fonte de verdade para ambas as extremidades. É uma declaração do que a Google deve esperar, e o router ainda tem de corresponder. A guia do gateway de par da Google mapeia essa declaração no trabalho de túnel, BGP, firewall e IKE que ainda deve.
Se uma linha não tiver responsável, será preenchida por quem estiver de turno durante a transição.
Mantenha as três funções de endereço separadas
Os endereços públicos de par transportam a troca IPsec externa. O par BGP interno pertence à ligação lógica protegida que corre sobre ele. Os prefixos LAN e VPC anunciados descrevem as cargas de trabalho por trás dessa ligação. Copiar o endereço interno de uma VM para o campo de par externo mistura as duas primeiras funções, e a falha parece um problema de negociação em vez de um erro de introdução de dados.
Planeie dois túneis de par correspondentes, um para cada interface HA VPN. Usar ambas as interfaces de nuvem não remove por si só o ponto de falha local, porque ambos os túneis podem continuar a aterrar no mesmo chassis.
Escreva a função do endereço ao lado de cada valor na folha de trabalho. Esse único hábito evita a maior parte da mistura.
Traduza a folha de trabalho para a versão Cisco
Comece pela documentação de par suportada ou por um modelo de configuração Google correspondente à sua plataforma e, depois, reconcilie cada marcador com a folha de trabalho. Verifique a autenticação IKEv2, as propostas ESP, o PFS e o modelo de túnel e encaminhamento em conjunto, porque uma incompatibilidade numa delas costuma manifestar-se como incompatibilidade noutra. Use a plataforma e a versão de software reais para selecionar o que é suportado, uma vez que uma receita Classic VPN é um ponto de partida diferente.
Mantenha o segredo partilhado fora de capturas de ecrã, anexos de tickets e notas de suporte. Uma chave pré-partilhada colada num comentário de caso é uma divulgação de credenciais, não um artefacto de resolução de problemas.
Se o modelo e a folha de trabalho discordarem, pare e resolva no papel. O dispositivo não vai arbitrar por si.
Aceite cada túnel com as suas próprias evidências
HA VPN precisa de sessões BGP, e uma negociação IKE bem-sucedida estabelece apenas a primeira fase. A sessão interna tem de subir, os prefixos previstos têm de ser anunciados e aceites, e têm de existir rotas úteis e permissões de firewall antes de o tráfego das cargas se mover. Registar isso como uma única luz verde esconde qual fase falhou realmente.
Registe evidências de aceitação por túnel: associações de segurança negociadas, estado do vizinho BGP, prefixos aprendidos esperados e o caminho previsto para a carga. Depois execute uma verificação controlada de falha e recuperação, porque um túnel que nunca falhou é um túnel cujo caminho de recuperação não foi testado.
Esse registo é reutilizável na próxima vez que o desenho mudar, e é a diferença entre uma interoperabilidade e um fragmento de comando cujos pressupostos se perderam.