GCP Cloud VPN: revise puerta de enlace, túnel y firewall en orden

Su consola muestra un túnel verde, la monitorización local sigue sin alcanzar una sola instancia y reconstruir el túnel parece la solución obvia. Rara vez lo es. Un túnel establecido solo demuestra que dos puertas de enlace terminaron el intercambio IKE. No dice nada sobre si algún paquete llegó a entrar en su VPC.

Cuatro decisiones separan ese icono verde de una respuesta, y fallan en un orden predecible. Abórdelas de la más barata a la más cara.

Tres objetos, y solo uno de ellos cifra

Una puerta de enlace VPN posee la dirección externa a la que cifra su par. En la consola nunca la crea a mano: elija o reserve una dirección dentro del formulario de conexión y la puerta de enlace aparece con ella. Una puerta de enlace HA ocupa dos direcciones en dos interfaces, lo que importa en la comprobación de cuotas más adelante.

Un túnel es el emparejamiento entre esa puerta de enlace y el par. Transporta el secreto compartido y los selectores de tráfico que promete proteger. En esos selectores empiezan la mayoría de los fallos silenciosos. Un túnel cuyo selector local cubre 10.0.0.0/24 no entregará 10.0.1.0/24, por muy sano que parezca el estado.

El extremo remoto mantiene su propia lista, normalmente llamada dominio de cifrado, y el hardware terminador la compara con la suya. Ningún lado negocia un selector que nunca se le dio.

El tipo de enrutamiento decide qué llega a la tabla de rutas

Cloud VPN ofrece tres formas de enrutamiento y no se mezclan limpiamente. El enrutamiento basado en políticas conserva los pares de selectores estáticos, el enrutamiento basado en rutas espera que usted añada rutas estáticas, y el enrutamiento dinámico anuncia prefijos a través de un Cloud Router por BGP. Elija uno a propósito.

Un túnel dinámico con rutas estáticas escritas a mano al lado produce una tabla de rutas que se vacía cada vez que la sesión BGP oscila.

El dinámico es la única forma que permite cambiar los prefijos protegidos sin reconstruir el túnel, y arrastra el Cloud Router al conjunto de objetos que debe verificar. Los selectores estáticos siguen siendo viables cuando el par es un firewall de hardware que no habla BGP. Entonces ambos extremos necesitan los mismos rangos, y la entrada más específica debe ganar en los dos. Una pareja que discrepa en una subred se establece y luego transporta la mitad de su tráfico.

La denegación implícita está detrás del túnel

El tráfico de entrada se evalúa contra una denegación implícita en la prioridad más baja, y esa regla no se preocupa de que el paquete llegara cifrado. Hasta que una regla de firewall nombre el rango local y el puerto en uso, el paquete se descifra, se inspecciona y se descarta. El registro de VPN permanece limpio en todo momento, porque el túnel hizo exactamente lo que prometió.

Lea en cambio el registro de denegaciones del firewall cuando el túnel esté activo y la prueba agote el tiempo, y luego limite una regla al rango de origen y a los puertos que necesita:

gcloud compute firewall-rules create allow-from-dc \
  --network=vpn-vpc \
  --direction=INGRESS \
  --source-ranges=192.168.10.0/24 \
  --allow=tcp:22,tcp:5432,icmp

Que funcione una sola dirección es una pista del firewall

La salida se comporta distinto, porque la regla de permiso implícita deja que las instancias envíen a cualquier parte. Un centro de datos que no alcanza una VM suele estar detrás de una ruta de salida perfectamente funcional en la otra dirección. Esa asimetría separa una omisión de firewall de un fallo de enrutamiento, ya que un fallo de enrutamiento rompe ambas direcciones a la vez. Pruebe la dirección inversa antes de editar una regla más.

Crear direcciones también es una operación de cuota. Un proyecto cerca de su límite de direcciones externas en uso rechaza la conexión con un error que parece un fallo de permisos.

Selectores, cuotas y luego las cuatro comprobaciones

Los túneles creados en la consola a veces devuelven un selector de tráfico remoto vacío desde gcloud compute vpn-tunnels describe, mientras las rutas generadas transportan el tráfico correctamente. Compare lo que registra la API con los rangos que realmente protege antes de decidir que el túnel está mal. Crearlo mediante la API o el SDK mantiene el selector explícito.

Las cuotas son el otro descuido fácil. Solicite el aumento antes de la ventana de mantenimiento y no durante ella, y compruebe el número de direcciones en el mismo proyecto que la puerta de enlace.

Trabaje de fuera hacia dentro: estado del par, ambas listas de selectores, una ruta por lado, una regla de entrada para el rango de origen y el puerto, y luego una captura de paquetes. Escriba la dirección de la puerta de enlace, ambas listas de selectores y el tipo de enrutamiento en el ticket de cambio mientras el túnel es nuevo, porque el siguiente ingeniero que añada una subred necesitará las tres cosas.