Limites do Cloud VPN que não se ajustam: duração do IKE e NAT do par
O Cloud VPN negoceia durações de IKE dentro de limites fixos e exige NAT um-para-um no par. Planeie o equipamento remoto em torno disso, não em torno do lado da Google.
Dê ao equipamento remoto uma duração de fase 1 de 24 horas e o túnel do Cloud VPN fica em baixo, mesmo que tudo do lado da Google esteja configurado corretamente. O par propõe um valor que o respondedor não aceitará, por isso a negociação ou falha por completo ou recomeça sem fim. O Cloud VPN limita a fase 1 a 36,000 segundos, dez horas, e esse limite não é uma definição que possa aumentar. A alteração pertence ao equipamento remoto.
O par pergunta, o respondedor decide
O IKE é um exercício de emparelhamento entre dois conjuntos de propostas. O túnel só se forma onde os conjuntos se sobrepõem dentro dos limites que o respondedor aceita, e é por isso que uma duração fora do intervalo não produz qualquer túnel parcial. O erro habitual é tratar a configuração do par como uma lista de desejos e não como uma proposta. Uma interseção vazia deixa o túnel em baixo, por muito corretos que sejam o encaminhamento e os seletores.
Leia o estado do próprio túnel antes de abrir um caso, porque o estado detalhado costuma nomear a fase que falhou:
gcloud compute vpn-tunnels describe office-tunnel \
--region europe-west1 \
--format="value(status,detailedStatus)"
Compare o que volta com o conjunto suportado para o seu tipo de gateway e versão de IKE, e registe ambos os seletores de tráfego enquanto está lá. Uma divergência de seletor dá o mesmo sintoma de túnel em baixo que uma divergência de algoritmo, e ao contrário do algoritmo, esta é sua para corrigir.
36,000 segundos é o teto
A fase 1 pára aos 36,000 segundos. Um equipamento configurado para 86,400 pede algo que o respondedor nunca aceitará, e tentar de novo não lhe muda a opinião. Traga a proposta remota de volta para o intervalo e a mesma configuração estabelece-se; a assimetria é toda a lição, porque pode baixar o seu próprio valor e não pode subir o da Google.
Escreva o valor escolhido nas notas de conceção. Caso contrário, o próximo engenheiro repete a experiência das 24 horas e chega à mesma parede.
O conjunto suportado é publicado por tipo de gateway e versão de IKE na visão geral do Cloud VPN, por isso leia a secção da sua topologia em vez de um guia geral de IKE.
Um túnel que cai segundo um horário
A fase 2 comporta-se de forma diferente: quando os dois extremos não concordam, a renovação de chaves segue o intervalo mais curto. Um par que trata a divergência como fatal deixa cair o túnel, pelo que uma divergência pode parecer duas falhas não relacionadas. Observe o ritmo de renovação de chaves, não apenas a primeira ligação. Um túnel que sobe e depois cai com um compasso regular é mais frequentemente uma divergência de duração do que um defeito de encaminhamento.
Correlacione esses carimbos de tempo de queda com os registos do próprio par antes de alterar seja o que for, porque uma mudança de seletor ou de rota pode imitar o mesmo ritmo. Se o compasso coincidir com o temporizador da fase 2, a causa está encontrada sem tocar numa proposta.
Os conjuntos vêm do tipo de gateway
Os conjuntos de cifra e integridade não são um perfil por túnel que edite como o strongSwan permite. Escolhe-os por tipo de gateway e versão de IKE, e procurar um perfil que não existe desperdiça uma tarde.
Um equipamento antigo que não oferece nada dentro do conjunto suportado deixa dois caminhos honestos: substituir o equipamento ou terminar num gateway de software que controle e encaminhar para a VPC a partir daí. Qualquer outra coisa é um remendo que falhará na próxima revisão.
Um endereço externo por equipamento
O endereço externo do par tem de corresponder um-para-um ao seu endereço interno. Um pool PAT sobrecarregado não pode funcionar, porque vários anfitriões atrás de um único endereço público não dão ao respondedor qualquer forma de os desmultiplexar. Onde vários anfitriões têm de partilhar um endereço, o túnel deve terminar num ponto que os consiga distinguir.
Mantenha também esse endereço externo estável. Mova o equipamento para trás de outro NAT e a associação quebra, mesmo que cada proposta continue a coincidir. Vale a pena anotar que valores são da Google e quais são seus: as durações, os conjuntos e o NAT um-para-um são fixos do lado deles, enquanto as propostas, os seletores, o encaminhamento e as prioridades BGP são seus.