Por qué un Apps Script no puede llegar a tu aplicación interna por VPN

El panel se abre sin problema en el navegador del portátil, pero el mismo script de hoja de cálculo falla con un error de dirección no disponible. Activar o desactivar la VPN no cambia nada, porque la solicitud nunca sale del portátil. Apps Script se ejecuta en la infraestructura de Google y abre su propia conexión desde allí. Ese único hecho decide todo el diseño.

Separa dos preguntas antes de cambiar nada: qué máquina envía la solicitud y qué credencial acepta el receptor.

La solicitud nunca empieza en tu portátil

Una pestaña del navegador envía desde el portátil, a través del adaptador VPN, el sufijo DNS interno y hacia la subred privada. UrlFetchApp envía desde un host gestionado por Google, así que ve los resolutores de Google, las direcciones de salida de Google y ninguna de tus rutas de túnel dividido. Los dos caminos comparten un documento de hoja de cálculo, no una ubicación de red. En el registro de acceso de la aplicación, el intento del script aparece como una dirección de Google en lugar de una dirección del conjunto de VPN, y esa es la confirmación más rápida que vas a obtener.

Por eso las correcciones locales no hacen nada. Apuntar el portátil a otro resolutor, reiniciar el cliente de VPN o añadir una entrada en hosts cambia la ruta del navegador y deja la ruta del script exactamente como estaba.

Qué descarta eso

Un punto de conexión solo interno no es accesible desde Apps Script, y la lista de IP permitidas es un sustituto débil del control de acceso en esta posición. Los rangos de salida de Google son amplios, se comparten con otros clientes y es imposible vincularlos a un solo script. La referencia de UrlFetchApp indica que las solicitudes se originan en el conjunto de IP de Google, que es la versión autorizada de esa afirmación. Abrir la aplicación interna a esos rangos admite tráfico que no puedes atribuir.

Las sesiones del navegador se comportan igual. Una cookie o una sesión SSO en el navegador del portátil no viaja con la solicitud, que es un cliente HTTPS nuevo sin estado de sesión. Todo lo que depende de una redirección SSO del navegador termina en esa redirección y no en tus datos.

Dos formas viables

La primera forma da al script una API aprobada. Publica el servicio interno detrás de una pasarela que autentique al llamante y luego haz que el script presente una credencial que la pasarela acepte, como un token de cuenta de servicio. En Apps Script eso significa una biblioteca OAuth2 o ScriptApp.getOAuthToken(), más una lista de identidades de llamante permitidas en el lado de la API en lugar de una lista de IP.

La segunda forma invierte la dirección. Una tarea interna consulta el sistema privado y publica un resultado controlado en un Sheet, un objeto de Cloud Storage o una tabla de BigQuery que el script lee. Una tarea de Cloud Run, un planificador local o un paso ETL existente pueden ser esa tarea, y ninguno de ellos necesita aceptar una conexión entrante. La hoja consume entonces un conjunto de datos en lugar de una interfaz.

Qué forma gana depende de la frescura, del control a nivel de campo y de quién tiene que poder auditar al lector.

Qué debe contener el resultado publicado

Un flujo en dirección inversa necesita un contrato explícito: los campos que lleva, el intervalo de actualización, el grupo de lectores y qué ocurre cuando la tarea interna falla. Sin esos cuatro, la hoja muestra en silencio las cifras de ayer. Añade una columna de marca de tiempo generada y un recuento de filas para que una publicación obsoleta o parcial sea visible en la propia hoja, sin que nadie abra un registro.

La dirección de API también necesita un contrato: qué credencial acepta la pasarela, qué ámbitos lleva el token y qué identidades de llamante se permiten. Una respuesta 200 que contiene una página de inicio de sesión no es una llamada correcta, así que revisa el cuerpo y no solo el código de estado.

Lee el error desde el lado correcto

Apps Script informa de un host inaccesible como una excepción de dirección no disponible, que no es el mensaje de conexión rechazada del navegador. Un 403 de la pasarela significa que la solicitud llegó y que se rechazó una credencial o una política. Una página de inicio de sesión HTML significa que la solicitud alcanzó una capa interactiva que un script no puede completar. Tres fallos distintos con tres responsables distintos.

Mantén el registro del script junto al resultado del navegador en lugar de sustituir uno por el otro. La pregunta que queda es entonces una decisión de integración corriente: dar a ese entorno el acceso que necesita o entregarle un resultado controlado.