Límites de Cloud VPN que non se poden axustar: duración de IKE e NAT do par

Dealle ao dispositivo remoto unha duración de fase 1 de 24 horas e o túnel de Cloud VPN queda abaixo, aínda que todo no lado de Google estea configurado correctamente. O par propón un valor que o respondedor non aceptará, así que a negociación ou falla por completo ou reiníciase indefinidamente. Cloud VPN limita a fase 1 a 36,000 segundos, dez horas, e ese tope non é un axuste que vostede poida subir. O cambio corresponde ao dispositivo remoto.

O par pregunta, o respondedor decide

IKE é un exercicio de coincidencia entre dous conxuntos de propostas. O túnel só se forma onde os conxuntos se solapan dentro dos límites que o respondedor acepta, e por iso unha duración fóra de rango non produce ningún túnel parcial. O erro habitual é tratar a configuración do par como unha lista de desexos e non como unha proposta. Unha intersección baleira deixa o túnel abaixo por moi correctos que sexan o enrutamento e os selectores.

Lea o estado do propio túnel antes de abrir un caso, porque o estado detallado adoita nomear a fase que fallou:

gcloud compute vpn-tunnels describe office-tunnel \
  --region europe-west1 \
  --format="value(status,detailedStatus)"

Compare o que devolve co conxunto admitido para o seu tipo de pasarela e versión de IKE, e anote ambos os selectores de tráfico mentres está alí. Unha discrepancia de selector dá o mesmo síntoma de túnel abaixo que unha discrepancia de algoritmo, e a diferenza do algoritmo, esta é súa para corrixir.

36,000 segundos é o teito

A fase 1 detense aos 36,000 segundos. Un dispositivo configurado a 86,400 pide algo que o respondedor nunca aceptará, e reintentalo non lle cambia a opinión. Devolva a proposta remota dentro do rango e a mesma configuración establécese; a asimetría é toda a lección, porque pode baixar o seu propio valor e non pode subir o de Google.

Escriba o valor escollido nas notas de deseño. Se non, o seguinte enxeñeiro repite o experimento de 24 horas e chega ao mesmo muro.

O conxunto admitido publícase por tipo de pasarela e versión de IKE na descrición xeral de Cloud VPN, así que lea a sección da súa topoloxía en lugar dunha guía xeral de IKE.

Un túnel que cae segundo un horario

A fase 2 compórtase distinto: cando os dous extremos non coinciden, a renovación de claves segue o intervalo máis curto. Un par que trata a discrepancia como fatal deixa caer o túnel, así que unha discrepancia pode parecer dous fallos non relacionados. Vixíe o ritmo de renovación de claves, non só a primeira conexión. Un túnel que sube e logo cae cun compás regular adoita ser unha discrepancia de duración máis que un defecto de enrutamento.

Correlacione esas marcas de tempo de caída cos rexistros do propio par antes de tocar nada, porque un cambio de selector ou de ruta pode imitar o mesmo ritmo. Se o compás coincide co temporizador da fase 2, a causa está atopada sen tocar ningunha proposta.

Os conxuntos veñen do tipo de pasarela

Os conxuntos de cifrado e integridade non son un perfil por túnel que vostede edite como lle permite strongSwan. Escólleos por tipo de pasarela e versión de IKE, e buscar un perfil que non existe desperdicia unha tarde.

Un dispositivo antigo que non ofrece nada dentro do conxunto admitido deixa dous camiños honestos: substituír o dispositivo ou terminar nunha pasarela de software que vostede controle e enrutar cara á VPC desde alí. Calquera outra cousa é unha solución improvisada que fallará a próxima revisión.

Un enderezo externo por dispositivo

O enderezo externo do par ten que corresponder un a un co seu enderezo interno. Un grupo PAT sobrecargado non pode funcionar, porque varios equipos detrás dunha soa dirección pública non lle dan ao respondedor ningunha forma de desmultiplexalos. Onde varios equipos teñen que compartir un enderezo, o túnel debe terminar nalgún punto que poida distinguilos.

Manteña tamén estable ese enderezo externo. Mova o dispositivo detrás doutro NAT e a asociación rompe aínda que cada proposta siga coincidindo. Paga a pena anotar que valores son de Google e cales son seus: as duracións, os conxuntos e o NAT un a un están fixos no seu lado, mentres que as propostas, os selectores, o enrutamento e as prioridades BGP son seus.