Hvorfor et Apps Script ikke kan nå din interne app over VPN

Dashboardet åbner fint i browseren på den bærbare computer, men det samme regnearksscript fejler med en fejl om utilgængelig adresse. At slå VPN til og fra ændrer intet, fordi anmodningen slet ikke forlader den bærbare computer. Apps Script kører på Googles infrastruktur og åbner sin egen forbindelse derfra. Den ene kendsgerning bestemmer hele designet.

Skil to spørgsmål ad, før du ændrer noget: hvilken maskine sender anmodningen, og hvilken legitimationsoplysning modtageren accepterer.

Anmodningen starter aldrig på din bærbare computer

En browservifte sender fra den bærbare computer, gennem VPN-adapteren, det interne DNS-suffiks og ind i det private undernet. UrlFetchApp sender fra en vært, som Google administrerer, så den ser Googles resolvere, Googles udgående adresser og ingen af dine split-tunnel-ruter. De to stier deler et regnearksdokument, ikke en netværksplacering. I applikationens adgangslog vises scriptets forsøg som en Google-adresse i stedet for en adresse fra VPN-puljen, og det er den hurtigste bekræftelse, du får.

Derfor gør lokale rettelser intet. At pege den bærbare computer mod en anden resolver, genstarte VPN-klienten eller tilføje en post i hosts ændrer browserens sti og efterlader scriptets sti præcis, som den var.

Hvad det udelukker

Et kun internt endepunkt kan ikke nås fra Apps Script, og en IP-tilladelsesliste er en svag erstatning for adgangskontrol på denne plads. Googles udgående intervaller er brede, deles med andre kunder og kan ikke bindes til ét script. UrlFetchApp-referencen angiver, at anmodninger stammer fra Googles IP-pulje, hvilket er den autoritative version af den påstand. At åbne den interne app for disse intervaller lukker trafik ind, som du ikke kan henføre.

Browsersessioner opfører sig på samme måde. En cookie eller en SSO-session i browseren på den bærbare computer rejser ikke med anmodningen, som er en frisk HTTPS-klient uden sessionstilstand. Alt, der afhænger af en SSO-omdirigering i browseren, ender ved den omdirigering i stedet for ved dine data.

To former, der kan fungere

Den første form giver scriptet et godkendt API. Udgiv den interne tjeneste bag en gateway, der autentificerer kalderen, og lad derefter scriptet fremlægge en legitimationsoplysning, som gatewayen accepterer, for eksempel et servicekontotoken. I Apps Script betyder det et OAuth2-bibliotek eller ScriptApp.getOAuthToken(), plus en tilladelsesliste over kalderidentiteter på API-siden i stedet for en IP-tilladelsesliste.

Den anden form vender retningen. Et internt job forespørger det private system og udgiver et kontrolleret resultat til et Sheet, et Cloud Storage-objekt eller en BigQuery-tabel, som scriptet læser. Et Cloud Run-job, en lokal planlægger eller et eksisterende ETL-trin kan alle være det job, og ingen af dem behøver at acceptere en indgående forbindelse. Regnearket forbruger derefter et datasæt i stedet for en grænseflade.

Hvilken form der vinder, afhænger af friskhed, feltniveaukontrol og af, hvem der skal kunne revidere læseren.

Hvad det udgivne resultat skal indeholde

En feed i omvendt retning har brug for en udtrykkelig kontrakt: de felter, den bærer, opdateringsintervallet, læsergruppen og hvad der sker, når det interne job fejler. Uden de fire viser regnearket stille gårsdagens tal. Tilføj en genereret tidsstempelkolonne og et rækkeantal, så en forældet eller delvis udgivelse er synlig i selve arket, uden at nogen åbner en log.

API-retningen har også brug for en kontrakt: hvilken legitimationsoplysning gatewayen accepterer, hvilke scopes tokenet bærer, og hvilke kalderidentiteter der er tilladt. Et 200-svar, der indeholder en log ind-side, er ikke et vellykket kald, så kontroller kroppen og ikke kun statuskoden.

Læs fejlen fra den rigtige side

Apps Script rapporterer en utilgængelig vært som en undtagelse om utilgængelig adresse, hvilket ikke er browserens besked om afvist forbindelse. En 403 fra gatewayen betyder, at anmodningen nåede frem, og at en legitimationsoplysning eller politik blev afvist. En HTML-log ind-side betyder, at anmodningen nåede et interaktivt lag, som et script ikke kan gennemføre. Tre forskellige fejl med tre forskellige ejere.

Hold scriptets log ved siden af browserens resultat i stedet for at erstatte det ene med det andet. Det resterende spørgsmål er så en almindelig integrationsbeslutning: giv det miljø den adgang, det har brug for, eller lever et kontrolleret resultat til det.