Pourquoi un Apps Script ne peut pas joindre votre application interne via le VPN

Le tableau de bord s’ouvre correctement dans le navigateur de l’ordinateur portable, mais le même script de feuille de calcul échoue avec une erreur d’adresse indisponible. Activer ou désactiver le VPN ne change rien, car la requête ne quitte jamais l’ordinateur portable. Apps Script s’exécute sur l’infrastructure de Google et ouvre sa propre connexion depuis là. Ce seul fait détermine toute la conception.

Séparez deux questions avant de changer quoi que ce soit : quelle machine envoie la requête, et quel justificatif le destinataire accepte.

La requête ne démarre jamais sur votre ordinateur portable

Un onglet de navigateur envoie depuis l’ordinateur portable, à travers l’adaptateur VPN, le suffixe DNS interne et vers le sous-réseau privé. UrlFetchApp envoie depuis un hôte géré par Google, il voit donc les résolveurs de Google, les adresses de sortie de Google et aucune de vos routes de tunnel divisé. Les deux chemins partagent un document de feuille de calcul, pas un emplacement réseau. Dans le journal d’accès de l’application, la tentative du script apparaît comme une adresse Google plutôt qu’une adresse du pool VPN, et c’est la confirmation la plus rapide que vous obtiendrez.

C’est pourquoi les correctifs locaux ne font rien. Pointer l’ordinateur portable vers un autre résolveur, redémarrer le client VPN ou ajouter une entrée dans hosts modifie le chemin du navigateur et laisse celui du script exactement tel qu’il était.

Ce que cela exclut

Un point de terminaison uniquement interne n’est pas joignable depuis Apps Script, et une liste d’IP autorisées est un piètre substitut au contrôle d’accès à cette place. Les plages de sortie de Google sont larges, partagées avec d’autres clients et impossibles à rattacher à un seul script. La référence UrlFetchApp indique que les requêtes proviennent du pool d’IP de Google, ce qui est la version faisant autorité de cette affirmation. Ouvrir l’application interne à ces plages admet du trafic que vous ne pouvez pas attribuer.

Les sessions de navigateur se comportent de la même façon. Un cookie ou une session SSO dans le navigateur de l’ordinateur portable ne voyage pas avec la requête, qui est un client HTTPS neuf sans état de session. Tout ce qui dépend d’une redirection SSO du navigateur s’arrête à cette redirection plutôt qu’à vos données.

Deux formes praticables

La première forme donne au script une API approuvée. Publiez le service interne derrière une passerelle qui authentifie l’appelant, puis faites présenter au script un justificatif que la passerelle accepte, comme un jeton de compte de service. Dans Apps Script, cela signifie une bibliothèque OAuth2 ou ScriptApp.getOAuthToken(), plus une liste d’identités d’appelant autorisées côté API plutôt qu’une liste d’IP.

La seconde forme inverse la direction. Une tâche interne interroge le système privé et publie un résultat maîtrisé dans un Sheet, un objet Cloud Storage ou une table BigQuery que le script lit. Une tâche Cloud Run, un planificateur local ou une étape ETL existante peuvent tous être cette tâche, et aucune d’elles n’a besoin d’accepter une connexion entrante. La feuille consomme alors un jeu de données plutôt qu’une interface.

La forme qui l’emporte dépend de la fraîcheur, du contrôle au niveau des champs et de qui doit pouvoir auditer le lecteur.

Ce que le résultat publié doit contenir

Un flux en sens inverse a besoin d’un contrat explicite : les champs qu’il transporte, l’intervalle de rafraîchissement, le groupe de lecteurs et ce qui se passe quand la tâche interne échoue. Sans ces quatre éléments, la feuille affiche discrètement les chiffres d’hier. Ajoutez une colonne d’horodatage générée et un nombre de lignes pour qu’une publication obsolète ou partielle soit visible dans la feuille elle-même, sans que personne n’ouvre un journal.

La direction API a aussi besoin d’un contrat : quel justificatif la passerelle accepte, quelles portées le jeton porte et quelles identités d’appelant sont autorisées. Une réponse 200 qui contient une page de connexion n’est pas un appel réussi, vérifiez donc le corps et pas seulement le code de statut.

Lisez l’erreur du bon côté

Apps Script signale un hôte injoignable comme une exception d’adresse indisponible, qui n’est pas le message de connexion refusée du navigateur. Un 403 de la passerelle signifie que la requête est arrivée et qu’un justificatif ou une politique a été rejeté. Une page de connexion HTML signifie que la requête a atteint une couche interactive qu’un script ne peut pas terminer. Trois défaillances différentes avec trois responsables différents.

Gardez le journal du script à côté du résultat du navigateur au lieu de remplacer l’un par l’autre. La question restante est alors une décision d’intégration ordinaire : donner à cet environnement l’accès dont il a besoin, ou lui livrer un résultat maîtrisé.