Per què un Apps Script no pot arribar a la vostra aplicació interna per VPN

El tauler s’obre bé al navegador de l’ordinador portàtil, però el mateix script de full de càlcul falla amb un error d’adreça no disponible. Activar o desactivar la VPN no canvia res, perquè la sol·licitud no surt mai de l’ordinador portàtil. Apps Script s’executa a la infraestructura de Google i obre la seva pròpia connexió des d’allà. Aquest sol fet decideix tot el disseny.

Separeu dues preguntes abans de canviar res: quina màquina envia la sol·licitud i quina credencial accepta el receptor.

La sol·licitud no comença mai al vostre ordinador portàtil

Una pestanya del navegador envia des de l’ordinador portàtil, a través de l’adaptador VPN, el sufix DNS intern i cap a la subxarxa privada. UrlFetchApp envia des d’un amfitrió gestionat per Google, així que veu els resolutors de Google, les adreces de sortida de Google i cap de les vostres rutes de túnel dividit. Els dos camins comparteixen un document de full de càlcul, no una ubicació de xarxa. Al registre d’accés de l’aplicació, l’intent de l’script apareix com una adreça de Google en lloc d’una adreça de la pool de VPN, que és la confirmació més ràpida que tindreu.

Per això les correccions locals no fan res. Apuntar l’ordinador portàtil a un altre resolutor, reiniciar el client de VPN o afegir una entrada a hosts canvia el camí del navegador i deixa el camí de l’script exactament com era.

Què descarta això

Un punt final només intern no és abastable des d’Apps Script, i la llista blanca d’IP és un substitut feble del control d’accés en aquesta posició. Els rangs de sortida de Google són amplis, compartits amb altres clients i impossibles de lligar a un sol script. La referència d’UrlFetchApp indica que les sol·licituds s’originen al pool d’IP de Google, que és la versió autoritzada d’aquesta afirmació. Obrir l’aplicació interna a aquests rangs admet trànsit que no podeu atribuir.

Les sessions del navegador es comporten igual. Una galeta o una sessió SSO al navegador de l’ordinador portàtil no viatja amb la sol·licitud, que és un client HTTPS nou sense estat de sessió. Tot el que depèn d’una redirecció SSO del navegador acaba en aquesta redirecció i no a les vostres dades.

Dues formes viables

La primera forma dona a l’script una API aprovada. Publiqueu el servei intern darrere d’una passarel·la que autentiqui el sol·licitant, i feu que l’script presenti una credencial que la passarel·la accepti, com un testimoni de compte de servei. A Apps Script això significa una biblioteca OAuth2 o ScriptApp.getOAuthToken(), més una llista blanca d’identitats de sol·licitant al costat de l’API en lloc d’una llista blanca d’IP.

La segona forma inverteix la direcció. Una tasca interna consulta el sistema privat i publica un resultat controlat en un Sheet, un objecte de Cloud Storage o una taula de BigQuery que l’script llegeix. Una tasca de Cloud Run, un planificador local o un pas ETL existent poden ser aquesta tasca, i cap d’ells no ha d’acceptar una connexió entrant. Llavors el full de càlcul consumeix un conjunt de dades en lloc d’una interfície.

Quina forma guanya depèn de la frescor, del control a nivell de camp i de qui ha de poder auditar el lector.

Què ha de contenir el resultat publicat

Un flux en direcció inversa necessita un contracte explícit: els camps que porta, l’interval d’actualització, el grup de lectors i què passa quan la tasca interna falla. Sense aquests quatre, el full de càlcul mostra en silenci les xifres d’ahir. Afegiu una columna de marca temporal generada i un recompte de files perquè una publicació obsoleta o parcial sigui visible al mateix full, sense que ningú obri un registre.

La direcció d’API també necessita un contracte: quina credencial accepta la passarel·la, quins àmbits porta el testimoni i quines identitats de sol·licitant es permeten. Una resposta 200 que conté una pàgina d’inici de sessió no és una crida correcta, així que reviseu el cos i no només el codi d’estat.

Llegiu l’error des del costat correcte

Apps Script informa d’un amfitrió no abastable com una excepció d’adreça no disponible, que no és el missatge de connexió rebutjada del navegador. Un 403 de la passarel·la significa que la sol·licitud va arribar i que s’ha rebutjat una credencial o una política. Una pàgina d’inici de sessió HTML significa que la sol·licitud va arribar a una capa interactiva que un script no pot completar. Tres fallades diferents amb tres propietaris diferents.

Manteniu el registre de l’script al costat del resultat del navegador en lloc de substituir l’un per l’altre. La pregunta que queda és llavors una decisió d’integració ordinària: doneu a aquest entorn l’accés que necessita o lliureu-li un resultat controlat.