Hvorfor et Apps Script ikke når den interne appen din over VPN

Dashbordet åpnes fint i nettleseren på den bærbare maskinen, men det samme regnearksskriptet feiler med en feil om utilgjengelig adresse. Å slå VPN av og på endrer ingenting, fordi forespørselen aldri forlater den bærbare maskinen. Apps Script kjører på Googles infrastruktur og åpner sin egen forbindelse derfra. Den ene kjensgjerningen avgjør hele designet.

Skill to spørsmål før du endrer noe: hvilken maskin sender forespørselen, og hvilken legitimasjon mottakeren godtar.

Forespørselen starter aldri på din bærbare maskin

En nettleserfane sender fra den bærbare maskinen, gjennom VPN-adapteren, det interne DNS-suffikset og inn i det private subnettet. UrlFetchApp sender fra en vert som Google administrerer, så den ser Googles resolvere, Googles utgangsadresser og ingen av dine split-tunnel-ruter. De to stiene deler et regnearkdokument, ikke en nettverksplassering. I applikasjonens tilgangslogg vises skriptets forsøk som en Google-adresse i stedet for en adresse fra VPN-poolen, og det er den raskeste bekreftelsen du får.

Derfor gjør lokale rettelser ingenting. Å peke den bærbare maskinen mot en annen resolver, starte VPN-klienten på nytt eller legge til en oppføring i hosts endrer nettleserens sti og lar skriptets sti være nøyaktig som den var.

Hva det utelukker

Et bare internt endepunkt kan ikke nås fra Apps Script, og en liste over tillatte IP-adresser er en svak erstatning for tilgangskontroll på denne plassen. Googles utgangsområder er brede, deles med andre kunder og kan ikke knyttes til ett skript. UrlFetchApp-referansen sier at forespørsler kommer fra Googles IP-pool, som er den autoritative versjonen av den påstanden. Å åpne den interne appen for disse områdene slipper inn trafikk du ikke kan tilskrive.

Nettleserøkter oppfører seg på samme måte. En cookie eller en SSO-økt i nettleseren på den bærbare maskinen reiser ikke med forespørselen, som er en ny HTTPS-klient uten øktstilstand. Alt som avhenger av en SSO-omdirigering i nettleseren, ender ved den omdirigeringen og ikke ved dataene dine.

To former som kan fungere

Den første formen gir skriptet et godkjent API. Publiser den interne tjenesten bak en gateway som autentiserer den som kaller, og la deretter skriptet legge fram en legitimasjon som gatewayen godtar, for eksempel et tjenestekontotoken. I Apps Script betyr det et OAuth2-bibliotek eller ScriptApp.getOAuthToken(), pluss en liste over tillatte kalleridentiteter på API-siden i stedet for en IP-liste.

Den andre formen snur retningen. En intern jobb spør det private systemet og publiserer et kontrollert resultat til et Sheet, et Cloud Storage-objekt eller en BigQuery-tabell som skriptet leser. En Cloud Run-jobb, en lokal planlegger eller et eksisterende ETL-trinn kan alle være den jobben, og ingen av dem trenger å godta en innkommende forbindelse. Regnearket bruker da et datasett i stedet for et grensesnitt.

Hvilken form som vinner avhenger av ferskhet, feltnivåkontroll og av hvem som må kunne revidere leseren.

Hva det publiserte resultatet må inneholde

En feed i motsatt retning trenger en uttrykkelig kontrakt: feltene den bærer, oppdateringsintervallet, lesergruppen og hva som skjer når den interne jobben feiler. Uten de fire viser regnearket stille gårsdagens tall. Legg til en generert tidsstempelkolonne og et radantall, slik at en utdatert eller delvis publisering er synlig i selve arket, uten at noen åpner en logg.

API-retningen trenger også en kontrakt: hvilken legitimasjon gatewayen godtar, hvilke scopes tokenet bærer og hvilke kalleridentiteter som er tillatt. Et 200-svar som inneholder en påloggingsside er ikke et vellykket kall, så sjekk kroppen og ikke bare statuskoden.

Les feilen fra riktig side

Apps Script rapporterer en utilgjengelig vert som et unntak om utilgjengelig adresse, som ikke er nettleserens melding om avvist forbindelse. En 403 fra gatewayen betyr at forespørselen kom fram og at en legitimasjon eller policy ble avvist. En HTML-påloggingsside betyr at forespørselen nådde et interaktivt lag som et skript ikke kan fullføre. Tre forskjellige feil med tre forskjellige ansvarlige.

Hold skriptets logg ved siden av nettleserens resultat i stedet for å erstatte det ene med det andre. Spørsmålet som gjenstår er da en vanlig integrasjonsbeslutning: gi det miljøet tilgangen det trenger, eller lever et kontrollert resultat til det.