Kvifor eit Apps Script ikkje når den interne appa di over VPN
Apps Script køyrer på netverket til Google, ikkje på den berbare maskina som har VPN-en. Design datastien for maskina som sender førespurnaden.
Dashbordet opnar fint i nettlesaren på den berbare maskina, men den same reknearkskrifta feilar med ein feil om utilgjengeleg adresse. Å slå VPN av og på endrar ingenting, fordi førespurnaden aldri forlèt den berbare maskina. Apps Script køyrer på infrastrukturen til Google og opnar si eiga tilknyting derfrå. Den eine kjensgjerninga avgjer heile designet.
Skil to spørsmål før du endrar noko: kva maskin som sender førespurnaden, og kva legitimasjon mottakaren godtek.
Førespurnaden startar aldri på den berbare maskina di
Ei nettlesarfane sender frå den berbare maskina, gjennom VPN-adapteren, det interne DNS-suffikset og inn i det private subnettet. UrlFetchApp sender frå ein vert som Google administrerer, så han ser resolverane til Google, utgangsadressene til Google og ingen av split-tunnel-rutene dine. Dei to stiane deler eit reknearkdokument, ikkje ein nettverksstad. I tilgangsloggen til applikasjonen blir forsøket til skrifta vist som ei Google-adresse i staden for ei adresse frå VPN-poolen, og det er den raskaste stadfestinga du får.
Difor gjer lokale rettingar ingenting. Å peike den berbare maskina mot ein annan resolver, starte VPN-klienten på nytt eller leggje til ei oppføring i hosts endrar stien til nettlesaren og lèt stien til skrifta vere nøyaktig som han var.
Kva det utelukkar
Eit berre internt endepunkt kan ikkje nåast frå Apps Script, og ei liste over tillatne IP-adresser er ei svak erstatning for tilgangskontroll på denne plassen. Utgangsområda til Google er breie, blir delte med andre kundar og kan ikkje knytast til eitt skript. UrlFetchApp-referansen seier at førespurnader kjem frå IP-poolen til Google, som er den autoritative versjonen av den påstanden. Å opne den interne appa for desse områda slepp inn trafikk du ikkje kan tilskrive.
Nettlesarøkter oppfører seg på same måte. Ein cookie eller ei SSO-økt i nettlesaren på den berbare maskina reiser ikkje med førespurnaden, som er ein ny HTTPS-klient utan økttilstand. Alt som er avhengig av ei SSO-omdirigering i nettlesaren, endar ved den omdirigeringa og ikkje ved dataa dine.
To former som kan fungere
Den første forma gir skrifta eit godkjent API. Publiser den interne tenesta bak ein gateway som autentiserer den som kallar, og la deretter skrifta leggje fram ein legitimasjon som gatewayen godtek, til dømes eit tenestekontotoken. I Apps Script tyder det eit OAuth2-bibliotek eller ScriptApp.getOAuthToken(), pluss ei liste over tillatne kallaridentitetar på API-sida i staden for ei IP-liste.
Den andre forma snur retninga. Ein intern jobb spør det private systemet og publiserer eit kontrollert resultat til eit Sheet, eit Cloud Storage-objekt eller ei BigQuery-tabell som skrifta les. Ein Cloud Run-jobb, ein lokal planleggjar eller eit eksisterande ETL-steg kan alle vere den jobben, og ingen av dei treng å godta ei innkomande tilknyting. Reknearket brukar då eit datasett i staden for eit grensesnitt.
Kva form som vinn, avheng av ferskleik, feltnivåkontroll og av kven som må kunne revidere lesaren.
Kva det publiserte resultatet må innehalde
Ein feed i motsett retning treng ein uttrykkeleg kontrakt: felta han ber, oppdateringsintervallet, lesargruppa og kva som skjer når den interne jobben feilar. Utan dei fire viser reknearket stille tala frå i går. Legg til ein generert tidsstempelkolonne og eit radtal, slik at ei utdatert eller delvis publisering er synleg i arket sjølv, utan at nokon opnar ein logg.
API-retninga treng òg ein kontrakt: kva legitimasjon gatewayen godtek, kva scopes tokenet ber og kva kallaridentitetar som er tillatne. Eit 200-svar som inneheld ei påloggingsside er ikkje eit vellukka kall, så sjekk kroppen og ikkje berre statuskoden.
Les feilen frå rett side
Apps Script rapporterer ein utilgjengeleg vert som eit unntak om utilgjengeleg adresse, som ikkje er meldinga til nettlesaren om avvist tilknyting. Ein 403 frå gatewayen tyder at førespurnaden kom fram og at ein legitimasjon eller ei policy vart avvist. Ei HTML-påloggingsside tyder at førespurnaden nådde eit interaktivt lag som eit skript ikkje kan fullføre. Tre ulike feil med tre ulike ansvarlege.
Hald loggen til skrifta ved sida av resultatet til nettlesaren i staden for å erstatte det eine med det andre. Spørsmålet som står att, er då ei vanleg integreringsavgjerd: gi det miljøet tilgangen det treng, eller lever eit kontrollert resultat til det.