Perché un Apps Script non riesce a raggiungere la tua applicazione interna via VPN

La dashboard si apre bene nel browser sul portatile, ma lo stesso script del foglio di calcolo fallisce con un errore di indirizzo non disponibile. Attivare o disattivare la VPN non cambia nulla, perché la richiesta non lascia mai il portatile. Apps Script viene eseguito sull’infrastruttura di Google e apre la propria connessione da lì. Questo unico fatto decide l’intero progetto.

Separa due domande prima di cambiare qualcosa: quale macchina invia la richiesta e quale credenziale accetta il destinatario.

La richiesta non parte mai dal tuo portatile

Una scheda del browser invia dal portatile, attraverso l’adattatore VPN, il suffisso DNS interno e verso la sottorete privata. UrlFetchApp invia da un host gestito da Google, quindi vede i resolver di Google, gli indirizzi di uscita di Google e nessuna delle tue rotte split-tunnel. I due percorsi condividono un documento di foglio di calcolo, non una posizione di rete. Nel registro degli accessi dell’applicazione, il tentativo dello script appare come un indirizzo Google invece che come un indirizzo del pool VPN, ed è la conferma più rapida che otterrai.

Per questo le correzioni locali non fanno nulla. Puntare il portatile a un altro resolver, riavviare il client VPN o aggiungere una voce in hosts cambia il percorso del browser e lascia quello dello script esattamente com’era.

Che cosa esclude

Un endpoint solo interno non è raggiungibile da Apps Script, e un elenco di IP consentiti è un sostituto debole del controllo degli accessi in questa posizione. Gli intervalli di uscita di Google sono ampi, condivisi con altri clienti e impossibili da legare a un solo script. Il riferimento di UrlFetchApp afferma che le richieste provengono dal pool di IP di Google, che è la versione autorevole di quell’affermazione. Aprire l’applicazione interna a quegli intervalli ammette traffico che non puoi attribuire.

Le sessioni del browser si comportano allo stesso modo. Un cookie o una sessione SSO nel browser del portatile non viaggia con la richiesta, che è un client HTTPS nuovo senza stato di sessione. Tutto ciò che dipende da un reindirizzamento SSO del browser finisce su quel reindirizzamento e non sui tuoi dati.

Due forme praticabili

La prima forma dà allo script un’API approvata. Pubblica il servizio interno dietro un gateway che autentica il chiamante, poi fai presentare allo script una credenziale che il gateway accetta, come un token di account di servizio. In Apps Script ciò significa una libreria OAuth2 o ScriptApp.getOAuthToken(), più un elenco di identità chiamanti consentite sul lato API invece di un elenco di IP.

La seconda forma inverte la direzione. Un processo interno interroga il sistema privato e pubblica un risultato controllato in un Sheet, in un oggetto Cloud Storage o in una tabella BigQuery che lo script legge. Un processo Cloud Run, uno scheduler locale o un passo ETL esistente possono tutti essere quel processo, e nessuno di loro deve accettare una connessione in entrata. Il foglio consuma allora un set di dati invece di un’interfaccia.

Quale forma vince dipende dalla freschezza, dal controllo a livello di campo e da chi deve poter verificare il lettore.

Che cosa deve contenere il risultato pubblicato

Un flusso in direzione inversa richiede un contratto esplicito: i campi che porta, l’intervallo di aggiornamento, il gruppo di lettori e che cosa succede quando il processo interno fallisce. Senza questi quattro, il foglio mostra in silenzio i numeri di ieri. Aggiungi una colonna di marca temporale generata e un conteggio delle righe così che una pubblicazione obsoleta o parziale sia visibile nel foglio stesso, senza che nessuno apra un registro.

Anche la direzione API richiede un contratto: quale credenziale accetta il gateway, quali scope porta il token e quali identità chiamanti sono consentite. Una risposta 200 che contiene una pagina di accesso non è una chiamata riuscita, quindi controlla il corpo e non solo il codice di stato.

Leggi l’errore dal lato giusto

Apps Script segnala un host irraggiungibile come eccezione di indirizzo non disponibile, che non è il messaggio di connessione rifiutata del browser. Un 403 dal gateway significa che la richiesta è arrivata e che una credenziale o una policy è stata rifiutata. Una pagina di accesso HTML significa che la richiesta ha raggiunto uno strato interattivo che uno script non può completare. Tre guasti diversi con tre responsabili diversi.

Tieni il registro dello script accanto al risultato del browser invece di sostituire l’uno con l’altro. La domanda che resta è allora una normale decisione di integrazione: dare a quell’ambiente l’accesso che gli serve, oppure consegnargli un risultato controllato.