Límites de Cloud VPN que no se pueden ajustar: duración de IKE y NAT del par

Dele al dispositivo remoto una duración de fase 1 de 24 horas y el túnel de Cloud VPN se queda caído, aunque todo en el lado de Google esté configurado correctamente. El par propone un valor que el respondedor no aceptará, así que la negociación o falla del todo o se reinicia indefinidamente. Cloud VPN limita la fase 1 a 36,000 segundos, diez horas, y ese tope no es un ajuste que usted pueda subir. El cambio corresponde al dispositivo remoto.

El par pregunta, el respondedor decide

IKE es un ejercicio de coincidencia entre dos conjuntos de propuestas. El túnel solo se forma donde los conjuntos se solapan dentro de los límites que el respondedor acepta, y por eso una duración fuera de rango no produce ningún túnel parcial. El error habitual es tratar la configuración del par como una lista de deseos y no como una propuesta. Una intersección vacía deja el túnel caído por muy correctos que sean el enrutamiento y los selectores.

Lea el estado del propio túnel antes de abrir un caso, porque el estado detallado suele nombrar la fase que falló:

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

Compare lo que devuelve con el conjunto admitido para su tipo de puerta de enlace y versión de IKE, y anote ambos selectores de tráfico mientras está allí. Una discrepancia de selector da el mismo síntoma de túnel caído que una discrepancia de algoritmo, y a diferencia del algoritmo, esta es suya para corregir.

36,000 segundos es el techo

La fase 1 se detiene a los 36,000 segundos. Un dispositivo configurado a 86,400 pide algo que el respondedor nunca aceptará, y reintentarlo no le cambia la opinión. Devuelva la propuesta remota dentro del rango y la misma configuración se establece; la asimetría es toda la lección, porque puede bajar su propio valor y no puede subir el de Google.

Escriba el valor elegido en las notas de diseño. De lo contrario, el siguiente ingeniero repite el experimento de 24 horas y llega al mismo muro.

El conjunto admitido se publica por tipo de puerta de enlace y versión de IKE en la descripción general de Cloud VPN, así que lea la sección de su topología en lugar de una guía general de IKE.

Un túnel que cae según un horario

La fase 2 se comporta distinto: cuando los dos extremos no coinciden, la renovación de claves sigue el intervalo más corto. Un par que trata la discrepancia como fatal deja caer el túnel, así que una discrepancia puede parecer dos fallos no relacionados. Vigile el ritmo de renovación de claves, no solo la primera conexión. Un túnel que sube y luego cae con un compás regular suele ser una discrepancia de duración más que un defecto de enrutamiento.

Correlacione esas marcas de tiempo de caída con los registros del propio par antes de tocar nada, porque un cambio de selector o de ruta puede imitar el mismo ritmo. Si el compás coincide con el temporizador de la fase 2, la causa está encontrada sin tocar ninguna propuesta.

Los conjuntos vienen del tipo de puerta de enlace

Los conjuntos de cifrado e integridad no son un perfil por túnel que usted edite como le permite strongSwan. Los elige por tipo de puerta de enlace y versión de IKE, y buscar un perfil que no existe desperdicia una tarde.

Un dispositivo antiguo que no ofrece nada dentro del conjunto admitido deja dos caminos honestos: sustituir el dispositivo o terminar en una puerta de enlace de software que usted controle y enrutar hacia la VPC desde allí. Cualquier otra cosa es un apaño que fallará la próxima revisión.

Una dirección externa por dispositivo

La dirección externa del par tiene que corresponder uno a uno con su dirección interna. Un grupo PAT sobrecargado no puede funcionar, porque varios equipos detrás de una sola dirección pública no dan al respondedor ninguna forma de desmultiplexarlos. Donde varios equipos tienen que compartir una dirección, el túnel debe terminar en algún punto que pueda distinguirlos.

Mantenga también estable esa dirección externa. Mueva el dispositivo detrás de otro NAT y la asociación se rompe aunque cada propuesta siga coincidiendo. Merece la pena anotar qué valores son de Google y cuáles son suyos: las duraciones, los conjuntos y el NAT uno a uno están fijos en su lado, mientras que las propuestas, los selectores, el enrutamiento y las prioridades BGP son suyos.