Waarom een Apps Script je interne app niet bereikt via VPN

Het dashboard opent prima in de browser op de laptop, maar hetzelfde spreadsheetscript mislukt met een fout over een niet-beschikbaar adres. De VPN aan- of uitzetten verandert niets, omdat het verzoek de laptop helemaal niet verlaat. Apps Script draait op Googles infrastructuur en opent daar zijn eigen verbinding. Dat ene feit bepaalt het hele ontwerp.

Scheid twee vragen voordat je iets wijzigt: welke machine het verzoek verstuurt, en welke referentie de ontvanger accepteert.

Het verzoek begint nooit op je laptop

Een browsertab verstuurt vanaf de laptop, via de VPN-adapter, het interne DNS-suffix en naar het privé-subnet. UrlFetchApp verstuurt vanaf een host die door Google wordt beheerd, dus het ziet Googles resolvers, Googles uitgaande adressen en geen van je split-tunnelroutes. De twee paden delen een spreadsheetdocument, niet een netwerklocatie. In het toegangslog van de applicatie verschijnt de poging van het script als een Google-adres in plaats van een adres uit de VPN-pool, en dat is de snelste bevestiging die je krijgt.

Daarom doen lokale correcties niets. De laptop naar een andere resolver wijzen, de VPN-client herstarten of een regel in hosts toevoegen verandert het pad van de browser en laat het pad van het script precies zoals het was.

Wat dat uitsluit

Een alleen intern eindpunt is niet bereikbaar vanuit Apps Script, en een lijst met toegestane IP’s is op deze plek een zwakke vervanging voor toegangscontrole. Googles uitgaande bereiken zijn breed, worden met andere klanten gedeeld en zijn niet aan één script te koppelen. De UrlFetchApp-referentie stelt dat verzoeken uit Googles IP-pool komen, wat de gezaghebbende versie van die bewering is. De interne app voor die bereiken openzetten laat verkeer binnen dat je niet kunt toeschrijven.

Browsersessies gedragen zich hetzelfde. Een cookie of een SSO-sessie in de browser van de laptop reist niet mee met het verzoek, dat een nieuwe HTTPS-client zonder sessiestatus is. Alles wat afhankelijk is van een SSO-doorverwijzing in de browser eindigt bij die doorverwijzing en niet bij je gegevens.

Twee werkbare vormen

De eerste vorm geeft het script een goedgekeurde API. Publiceer de interne dienst achter een gateway die de aanroeper authenticeert, en laat het script vervolgens een referentie presenteren die de gateway accepteert, zoals een servicetoken voor een serviceaccount. In Apps Script betekent dat een OAuth2-bibliotheek of ScriptApp.getOAuthToken(), plus een lijst met toegestane aanroepersidentiteiten aan de API-kant in plaats van een IP-lijst.

De tweede vorm keert de richting om. Een interne taak bevraagt het privésysteem en publiceert een gecontroleerd resultaat naar een Sheet, een Cloud Storage-object of een BigQuery-tabel die het script leest. Een Cloud Run-taak, een lokale scheduler of een bestaande ETL-stap kunnen allemaal die taak zijn, en geen van hen hoeft een inkomende verbinding te accepteren. De spreadsheet gebruikt dan een dataset in plaats van een interface.

Welke vorm wint hangt af van versheid, controle op veldniveau en van wie de lezer moet kunnen controleren.

Wat het gepubliceerde resultaat moet bevatten

Een feed in omgekeerde richting heeft een uitdrukkelijk contract nodig: de velden die hij draagt, het verversingsinterval, de lezersgroep en wat er gebeurt als de interne taak mislukt. Zonder die vier toont de spreadsheet stil de cijfers van gisteren. Voeg een gegenereerde tijdstempelkolom en een rijaantal toe, zodat een verouderde of gedeeltelijke publicatie zichtbaar is in het blad zelf, zonder dat iemand een log opent.

De API-richting heeft ook een contract nodig: welke referentie de gateway accepteert, welke scopes het token draagt en welke aanroepersidentiteiten zijn toegestaan. Een 200-antwoord met een inlogpagina is geen geslaagde aanroep, dus controleer de body en niet alleen de statuscode.

Lees de fout van de juiste kant

Apps Script meldt een onbereikbare host als een uitzondering over een niet-beschikbaar adres, wat niet de melding van de browser over een geweigerde verbinding is. Een 403 van de gateway betekent dat het verzoek aankwam en dat een referentie of beleid is geweigerd. Een HTML-inlogpagina betekent dat het verzoek een interactieve laag bereikte die een script niet kan afronden. Drie verschillende fouten met drie verschillende verantwoordelijken.

Houd het log van het script naast het resultaat van de browser in plaats van het een door het ander te vervangen. De resterende vraag is dan een gewone integratiebeslissing: geef die omgeving de toegang die ze nodig heeft, of lever haar een gecontroleerd resultaat.