Por que un Apps Script non pode chegar á túa aplicación interna por VPN

O panel ábrese ben no navegador do portátil, pero o mesmo script de folla de cálculo falla cun erro de enderezo non dispoñible. Activar ou desactivar a VPN non cambia nada, porque a solicitude nunca sae do portátil. Apps Script execútase na infraestrutura de Google e abre a súa propia conexión desde alí. Ese único feito decide todo o deseño.

Separa dúas preguntas antes de cambiar nada: que máquina envía a solicitude e que credencial acepta o receptor.

A solicitude nunca comeza no teu portátil

Unha lapela do navegador envía desde o portátil, a través do adaptador VPN, o sufixo DNS interno e cara á subrede privada. UrlFetchApp envía desde un servidor xestionado por Google, así que ve os resolvedores de Google, os enderezos de saída de Google e ningunha das túas rutas de túnel dividido. As dúas rutas comparten un documento de folla de cálculo, non unha localización de rede. No rexistro de acceso da aplicación, o intento do script aparece como un enderezo de Google en lugar dun enderezo do conxunto de VPN, e esa é a confirmación máis rápida que vas obter.

Por iso as correccións locais non fan nada. Apuntar o portátil a outro resolvedor, reiniciar o cliente VPN ou engadir unha entrada en hosts cambia a ruta do navegador e deixa a ruta do script exactamente como estaba.

Que descarta iso

Un punto final só interno non é accesible desde Apps Script, e a lista de IP permitidas é un substituto feble do control de acceso nesta posición. Os rangos de saída de Google son amplos, compártense con outros clientes e é imposible ligalos a un só script. A referencia de UrlFetchApp indica que as solicitudes se orixinan no conxunto de IP de Google, que é a versión autorizada desa afirmación. Abrir a aplicación interna a eses rangos admite tráfico que non podes atribuír.

As sesións do navegador compórtanse igual. Unha cookie ou unha sesión SSO no navegador do portátil non viaxa coa solicitude, que é un cliente HTTPS novo sen estado de sesión. Todo o que depende dunha redirección SSO do navegador remata nesa redirección e non nos teus datos.

Dúas formas viables

A primeira forma dálle ao script unha API aprobada. Publica o servizo interno detrás dunha pasarela que autentique o chamante e logo fai que o script presente unha credencial que a pasarela acepte, como un token de conta de servizo. En Apps Script iso significa unha biblioteca OAuth2 ou ScriptApp.getOAuthToken(), máis unha lista de identidades de chamante permitidas no lado da API en lugar dunha lista de IP.

A segunda forma inverte a dirección. Unha tarefa interna consulta o sistema privado e publica un resultado controlado nun Sheet, nun obxecto de Cloud Storage ou nunha táboa de BigQuery que o script le. Unha tarefa de Cloud Run, un planificador local ou un paso ETL existente poden ser esa tarefa, e ningún deles necesita aceptar unha conexión entrante. A folla consume entón un conxunto de datos en lugar dunha interface.

Que forma gaña depende da frescura, do control a nivel de campo e de quen ten que poder auditar o lector.

Que debe conter o resultado publicado

Un fluxo en dirección inversa necesita un contrato explícito: os campos que leva, o intervalo de actualización, o grupo de lectores e que ocorre cando a tarefa interna falla. Sen eses catro, a folla mostra en silencio as cifras de onte. Engade unha columna de marca temporal xerada e un reconto de filas para que unha publicación obsoleta ou parcial sexa visible na propia folla, sen que ninguén abra un rexistro.

A dirección de API tamén necesita un contrato: que credencial acepta a pasarela, que ámbitos leva o token e que identidades de chamante se permiten. Unha resposta 200 que contén unha páxina de inicio de sesión non é unha chamada correcta, así que revisa o corpo e non só o código de estado.

Le o erro desde o lado correcto

Apps Script informa dun servidor inaccesible como unha excepción de enderezo non dispoñible, que non é a mensaxe de conexión rexeitada do navegador. Un 403 da pasarela significa que a solicitude chegou e que se rexeitou unha credencial ou unha política. Unha páxina de inicio de sesión HTML significa que a solicitude alcanzou unha capa interactiva que un script non pode completar. Tres fallos distintos con tres responsables distintos.

Mantén o rexistro do script xunto ao resultado do navegador en lugar de substituír un polo outro. A pregunta que queda é entón unha decisión de integración corrente: darlle a ese ambiente o acceso que necesita ou entregarlle un resultado controlado.