Waarom ’n Apps Script nie jou interne toepassing oor VPN kan bereik nie

Die paneelbord open fyn in die blaaier op die skootrekenaar, maar dieselfde sigbladskrip misluk met die fout dat die adres onbeskikbaar is. Die VPN aan- en afskakel verander niks, want die versoek verlaat glad nie die skootrekenaar nie. Apps Script voer op Google se infrastruktuur uit en maak sy eie verbinding daarvandaan oop. Daardie enkele feit bepaal die hele ontwerp.

Skei twee vrae voordat jy enigiets verander: watter masjien die versoek stuur, en watter geloofsbrief die ontvanger aanvaar.

Die versoek begin nooit op jou skootrekenaar nie

’n Blaaier-oortjie stuur vanaf die skootrekenaar, deur die VPN-adapter, die interne DNS-agtervoegsel en in die private subnet in. UrlFetchApp stuur vanaf ’n gasheer wat Google bestuur, so dit sien Google se oplossers, Google se uitgangsadresse en nie een van jou split-tunnel-roetes nie. Die twee paaie deel ’n sigbladdokument, nie ’n netwerklokasie nie. In die toepassing se toegangslog verskyn die skrip se poging as ’n Google-adres eerder as ’n VPN-poeladres, wat die vinnigste bevestiging is wat jy sal kry.

Daarom doen plaaslike regstellings niks. Om die skootrekenaar na ’n ander oplosser te wys, die VPN-kliënt te herbegin of ’n hosts-inskrywing by te voeg, verander die blaaier se pad en laat die skrip se pad presies soos dit was.

Wat dit uitsluit

’n Slegs-interne eindpunt is onbereikbaar vanaf Apps Script, en IP-allowlisting is op hierdie plek ’n swak plaasvervanger vir toegangsbeheer. Google se uitgangreekse is wyd, word met ander kliënte gedeel en kan nie aan een skrip gekoppel word nie. Die UrlFetchApp-verwysing sê dat versoeke uit Google se IP-poel kom, wat die gesaghebbende weergawe van daardie bewering is. Om die interne toepassing vir daardie reekse oop te maak, laat verkeer in wat jy nie kan toeskryf nie.

Blaaier-sessies werk dieselfde. ’n Cookie of ’n SSO-sessie in die skootrekenaar se blaaier reis nie saam met die versoek nie, wat ’n vars HTTPS-kliënt sonder sessietoestand is. Enigiets wat van ’n blaaier-SSO-herleiding afhang, eindig by daardie herleiding eerder as by jou data.

Twee werkbare vorms

Die eerste vorm gee die skrip ’n goedgekeurde API. Publiseer die interne diens agter ’n poort wat die oproeper authentiseer, en laat die skrip dan ’n geloofsbrief voorlê wat daardie poort aanvaar, soos ’n diensrekening-token. In Apps Script beteken dit ’n OAuth2-biblioteek of ScriptApp.getOAuthToken(), plus ’n oproeperidentiteit-allowlist aan die API-kant eerder as ’n IP-allowlist.

Die tweede vorm keer die rigting om. ’n Interne taak vra die private stelsel uit en publiseer ’n beheerde resultaat na ’n Sheet, ’n Cloud Storage-objek of ’n BigQuery-tabel wat die skrip lees. ’n Cloud Run-taak, ’n plaaslike skeduleerder of ’n bestaande ETL-stap kan almal daardie taak wees, en nie een van hulle hoef ’n inkomende verbinding te aanvaar nie. Die sigblad verbruik dan ’n datastel eerder as ’n koppelvlak.

Watter vorm wen, hang af van varsheid, beheer op veldvlak en wie die leser moet kan ouditeer.

Wat die gepubliseerde resultaat moet bevat

’n Voedingsbron in die omgekeerde rigting het ’n eksplisiete kontrak nodig: die velde wat dit dra, die verversingsinterval, die lesergroep en wat gebeur wanneer die interne taak misluk. Sonder daardie vier wys die sigblad stilweg gister se syfers. Voeg ’n gegenereerde tydstempel-kolom en ’n ry-telling by sodat ’n verouderde of gedeeltelike publikasie in die sigblad self sigbaar is, sonder dat iemand ’n log hoef oop te maak.

Die API-rigting het ook ’n kontrak nodig: watter geloofsbrief die poort aanvaar, watter scopes die token dra en watter oproeperidentiteite toegelaat word. ’n 200-antwoord wat ’n aanmeldbladsy bevat, is nie ’n suksesvolle oproep nie, so kyk na die liggaam en nie net na die statuskode nie.

Lees die fout van die regte kant

Apps Script rapporteer ’n onbereikbare gasheer as ’n adres-onbeskikbaar-uitsondering, wat nie die blaaier se verbinding-weier-fout is nie. ’n 403 van die poort beteken die versoek het aangekom en ’n geloofsbrief of beleid is verwerp. ’n HTML-aanmeldbladsy beteken die versoek het ’n interaktiewe laag bereik wat ’n skrip nie kan voltooi nie. Drie verskillende mislukkings met drie verskillende eienaars.

Hou die skrip se log langs die blaaier se resultaat in plaas daarvan om die een met die ander te vervang. Die oorblywende vraag is dan ’n gewone integrasiebesluit: gee daardie omgewing die toegang wat dit nodig het, of lewer ’n beheerde resultaat aan hom.