Varför ett Apps Script inte når din interna app över VPN

Instrumentpanelen öppnas fint i webbläsaren på den bärbara datorn, men samma kalkylbladsskript misslyckas med ett fel om otillgänglig adress. Att slå på eller av VPN ändrar ingenting, eftersom begäran aldrig lämnar den bärbara datorn. Apps Script körs på Googles infrastruktur och öppnar sin egen anslutning därifrån. Det enda faktumet avgör hela designen.

Skilj på två frågor innan du ändrar något: vilken maskin som skickar begäran, och vilken autentiseringsuppgift mottagaren accepterar.

Begäran börjar aldrig på din bärbara dator

En webbläsarflik skickar från den bärbara datorn, genom VPN-adaptern, det interna DNS-suffixet och in i det privata subnätet. UrlFetchApp skickar från en värd som Google administrerar, så den ser Googles resolvers, Googles utgående adresser och ingen av dina split-tunnel-rutter. De två vägarna delar ett kalkylbladsdokument, inte en nätverksplats. I applikationens åtkomstlogg visas skriptets försök som en Google-adress i stället för en adress från VPN-poolen, och det är den snabbaste bekräftelsen du får.

Därför gör lokala rättelser ingenting. Att peka den bärbara datorn mot en annan resolver, starta om VPN-klienten eller lägga till en post i hosts ändrar webbläsarens väg och lämnar skriptets väg exakt som den var.

Vad det utesluter

En enbart intern slutpunkt går inte att nå från Apps Script, och en lista över tillåtna IP-adresser är en svag ersättning för åtkomstkontroll på den här platsen. Googles utgående intervall är breda, delas med andra kunder och kan inte knytas till ett enda skript. UrlFetchApp-referensen anger att begäranden kommer från Googles IP-pool, vilket är den auktoritativa versionen av det påståendet. Att öppna den interna appen för dessa intervall släpper in trafik som du inte kan tillskriva.

Webbläsarsessioner beter sig på samma sätt. En cookie eller en SSO-session i webbläsaren på den bärbara datorn följer inte med begäran, som är en ny HTTPS-klient utan sessionstillstånd. Allt som beror på en SSO-omdirigering i webbläsaren slutar vid den omdirigeringen och inte vid dina data.

Två former som fungerar

Den första formen ger skriptet ett godkänt API. Publicera den interna tjänsten bakom en gateway som autentiserar anroparen och låt sedan skriptet lägga fram en autentiseringsuppgift som gatewayen accepterar, till exempel en token för ett tjänstekonto. I Apps Script betyder det ett OAuth2-bibliotek eller ScriptApp.getOAuthToken(), plus en lista över tillåtna anropsidentiteter på API-sidan i stället för en IP-lista.

Den andra formen vänder riktningen. Ett internt jobb frågar det privata systemet och publicerar ett kontrollerat resultat till ett Sheet, ett Cloud Storage-objekt eller en BigQuery-tabell som skriptet läser. Ett Cloud Run-jobb, en lokal schemaläggare eller ett befintligt ETL-steg kan alla vara det jobbet, och ingen av dem behöver acceptera en inkommande anslutning. Kalkylbladet konsumerar då en datamängd i stället för ett gränssnitt.

Vilken form som vinner beror på färskhet, kontroll på fältnivå och på vem som måste kunna granska läsaren.

Vad det publicerade resultatet måste innehålla

Ett flöde i omvänd riktning behöver ett uttryckligt avtal: fälten det bär, uppdateringsintervallet, läsargruppen och vad som händer när det interna jobbet misslyckas. Utan de fyra visar kalkylbladet stilla gårdagens siffror. Lägg till en genererad tidsstämpelkolumn och ett radantal så att en inaktuell eller delvis publicering syns i själva arket, utan att någon öppnar en logg.

API-riktningen behöver också ett avtal: vilken autentiseringsuppgift gatewayen accepterar, vilka scopes token bär och vilka anropsidentiteter som är tillåtna. Ett 200-svar som innehåller en inloggningssida är inte ett lyckat anrop, så kontrollera brödtexten och inte bara statuskoden.

Läs felet från rätt sida

Apps Script rapporterar en onåbar värd som ett undantag om otillgänglig adress, vilket inte är webbläsarens meddelande om nekad anslutning. En 403 från gatewayen betyder att begäran kom fram och att en autentiseringsuppgift eller policy avvisades. En HTML-inloggningssida betyder att begäran nådde ett interaktivt lager som ett skript inte kan slutföra. Tre olika fel med tre olika ansvariga.

Håll skriptets logg bredvid webbläsarens resultat i stället för att ersätta det ena med det andra. Frågan som återstår är då ett vanligt integrationsbeslut: ge den miljön den åtkomst den behöver, eller leverera ett kontrollerat resultat till den.