Acceso remoto de desarrolladores a una VPC de Google Cloud: elija el camino
IAP, una VPN de acceso remoto y Cloud VPN resuelven problemas distintos. Encaje el camino con los destinos y las identidades antes de abrir un receptor.
Un desarrollador necesita una sesión SSH, un puerto de base de datos o acceso amplio a una docena de servicios privados, y cada una de esas solicitudes parece la misma pregunta. No lo es. Los destinos, los protocolos y las identidades implicadas deciden qué camino de acceso de Google Cloud encaja, y elegir el más amplio por defecto crea trabajo que usted no tenía que asumir.
Anote los destinos y los protocolos
Enumere las direcciones privadas, los puertos y los protocolos que el trabajo necesita de verdad, y después marque qué identidades deben autenticarse por separado. Un puerto de base de datos y una zona DNS privada son requisitos distintos, y un servicio UDP descarta por completo una de las opciones siguientes. Una lista escrita también muestra lo que no está concediendo. Esa es la parte que preguntan los revisores.
Hágalo antes de abrir un receptor. La lista se convierte más tarde en la prueba de aceptación, y es la única forma fiable de distinguir un túnel estrecho de uno amplio que funciona por casualidad.
IAP para unos pocos servicios TCP
El reenvío TCP de Identity-Aware Proxy da un túnel autenticado hacia recursos de VM elegibles sin exponer el servicio a internet. La forma cotidiana es gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a, y un solo puerto puede reenviarse localmente con gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a.
Tres cosas deben coincidir: quien llama necesita el rol de acceso al túnel de IAP, el cortafuegos debe admitir el rango de origen de IAP y el destino debe ser alcanzable en la instancia. La autorización para crear el túnel no es una credencial de base de datos, un inicio de sesión SSH ni una sesión RDP, así que deje la autenticación de la aplicación donde corresponde.
El reenvío TCP de IAP no es una VPN de capa tres. Lleva TCP a un destino seleccionado, no tráfico IP arbitrario ni UDP, y encaja mal cuando una aplicación necesita DNS privado en muchos servicios.
Una VPN de acceso remoto para una alcanzabilidad más amplia
Cuando se requieren varios destinos, protocolos o zonas DNS privadas, la mejor forma es una VPN de acceso remoto gestionada de forma explícita en una VM o un dispositivo compatible. Ese despliegue es independiente de Cloud VPN gestionado por Google: usted posee el alta de identidad del cliente, las actualizaciones de software, las rutas del cliente y las rutas de retorno de la VPC.
Planifique la lista completa, no solo el receptor público. Incluya el conjunto de túneles, la ruta de la VPC de vuelta, los controles de reenvío, la resolución DNS y la política de acceso por servicio. Una VPN que conecta pero no puede resolver nombres internos hace fracasar el flujo de trabajo del desarrollador con la misma plenitud que una que nunca conecta.
Cloud VPN es una puerta de sitio, no un perfil de portátil
Google Cloud VPN conecta puertas pares mediante IPsec, y sus preguntas frecuentes separan ese papel de sitio a sitio del acceso de cliente a puerta. Crear un túnel no produce un perfil que un empleado importe en un portátil. La distinción importa cuando alguien pide un perfil de Cloud VPN. La respuesta es otro producto.
Lo que una puerta hace bien es dar a las máquinas detrás de una red de oficina una ruta hacia la VPC. No autentica a cada empleado ni concede permisos de aplicación, así que esas políticas se quedan en las capas de red y aplicación, donde pueden aplicarse por identidad.
Verifique y registre
Pruebe primero el destino más estrecho, después el que requiere DNS y luego un destino que debe seguir denegado. Ejecute cada prueba desde el mismo cliente que usará el camino en producción, porque una prueba que funciona desde una estación de trabajo de administrador demuestra poco sobre un portátil de desarrollador con otra red.
Registre el modelo elegido, los destinos que cubre, las identidades que autentica y el comportamiento de fallo cuando el camino no está disponible. Ese registro es lo que impide que la siguiente solicitud amplíe el túnel en silencio en lugar de añadir un destino a un diseño documentado.