Bakit hindi maabot ng isang Apps Script ang iyong panloob na app sa VPN

Maayos na bumubukas ang dashboard sa browser sa laptop, ngunit nabibigo ang parehong script ng spreadsheet na may error na hindi available ang address. Walang binabago ang pag-on o pag-off ng VPN, dahil hindi man lang umaalis ang kahilingan sa laptop. Tumakbo ang Apps Script sa imprastruktura ng Google at doon nagbubukas ng sarili nitong koneksyon. Ang nag-iisang katotohanang iyon ang nagtatakda sa buong disenyo.

Paghiwalayin ang dalawang tanong bago baguhin ang anuman: aling makina ang nagpapadala ng kahilingan, at aling kredensyal ang tinatanggap ng tatanggap.

Hindi kailanman nagsisimula ang kahilingan sa iyong laptop

Nagpapadala ang tab ng browser mula sa laptop, sa pamamagitan ng adapter ng VPN, ng panloob na suffix ng DNS at papasok sa pribadong subnet. Nagpapadala ang UrlFetchApp mula sa host na pinamamahalaan ng Google, kaya nakikita nito ang mga resolver ng Google, ang mga address ng labasan ng Google at wala ni isa sa iyong mga ruta ng split-tunnel. Isang dokumento ng spreadsheet ang ibinabahagi ng dalawang daanan, hindi isang lokasyon sa network. Sa log ng access ng app, lumilitaw ang pagtatangka ng script bilang isang address ng Google sa halip na address mula sa pool ng VPN, at iyon ang pinakamabilis na kumpirmasyong makukuha mo.

Kaya wala ring nagagawa ang mga lokal na pagwawasto. Ang pagturo ng laptop sa ibang resolver, pag-restart ng kliyente ng VPN o pagdaragdag ng entry sa hosts ay nagbabago sa daanan ng browser at iniiwan ang daanan ng script na eksaktong tulad ng dati.

Ano ang ibinubukod nito

Ang endpoint na panloob lamang ay hindi maabot mula sa Apps Script, at ang listahan ng pinapayagang IP ay mahinang kapalit ng kontrol sa access sa posisyong ito. Malawak ang mga saklaw ng labasan ng Google, ibinabahagi sa ibang kostumer at imposibleng itali sa isang script. Ang reperensya ng UrlFetchApp ay nagsasabi na nagmumula ang mga kahilingan sa pool ng IP ng Google, na siyang awtoridad na bersyon ng pahayag na iyon. Ang pagbubukas ng panloob na app sa mga saklaw na iyon ay tumatanggap ng trapikong hindi mo maipapamahagi.

Ganoon din ang ugali ng mga sesyon ng browser. Ang cookie o sesyon ng SSO sa browser ng laptop ay hindi naglalakbay kasama ng kahilingan, na isang bagong kliyente ng HTTPS na walang estado ng sesyon. Anumang umaasa sa pag-redirect ng SSO sa browser ay nagtatapos sa redirect na iyon at hindi sa iyong data.

Dalawang anyong magagawa

Ang unang anyo ay nagbibigay sa script ng aprubadong API. Ilathala ang panloob na serbisyo sa likod ng gateway na nagpapatunay sa tumatawag, pagkatapos ay ipakita ng script ang kredensyal na tinatanggap ng gateway, tulad ng token ng service account. Sa Apps Script, ibig sabihin nito ay aklatang OAuth2 o ScriptApp.getOAuthToken(), kasama ng listahan ng pinapayagang pagkakakilanlan ng tumatawag sa panig ng API sa halip na listahan ng IP.

Binabaligtad ng ikalawang anyo ang direksyon. Ang panloob na trabaho ay nagtatanong sa pribadong sistema at naglalathala ng kontroladong resulta sa isang Sheet, object ng Cloud Storage o talahanayan ng BigQuery na binabasa ng script. Ang trabaho sa Cloud Run, lokal na scheduler o umiiral na hakbang ng ETL ay maaaring maging ganitong trabaho, at wala sa kanila ang kailangang tumanggap ng papasok na koneksyon. Ang spreadsheet ay kumakain ng dataset sa halip na interface.

Alin ang mananalo ay nakasalalay sa kasariwaan, kontrol sa antas ng field at kung sino ang dapat makapag-audit ng mambabasa.

Ano ang dapat taglayin ng inilathalang resulta

Ang feed sa baligtad na direksyon ay nangangailangan ng malinaw na kontrata: ang mga field na dala nito, ang agwat ng pag-refresh, ang grupo ng mambabasa at ano ang nangyayari kapag nabigo ang panloob na trabaho. Kung wala ang apat na iyon, tahimik na ipinapakita ng spreadsheet ang bilang ng kahapon. Magdagdag ng nabuong kolumna ng timestamp at bilang ng hilera upang makita mismo sa sheet ang lipas o bahagyang paglathala, nang walang magbukas ng log.

Kailangan din ng kontrata ng direksyon ng API: aling kredensyal ang tinatanggap ng gateway, aling scopes ang dala ng token at aling mga pagkakakilanlan ng tumatawag ang pinapayagan. Ang 200 na sagot na may pahina ng pag-sign in ay hindi matagumpay na tawag, kaya suriin ang katawan at hindi lamang ang status code.

Basahin ang error mula sa tamang panig

Iniuulat ng Apps Script ang hindi maabot na host bilang exception ng hindi available na address, na hindi ang mensahe ng browser tungkol sa tinanggihang koneksyon. Ang 403 mula sa gateway ay nangangahulugang nakarating ang kahilingan at tinanggihan ang isang kredensyal o patakaran. Ang HTML na pahina ng pag-sign in ay nangangahulugang naabot ng kahilingan ang interaktibong layer na hindi kayang tapusin ng isang script. Tatlong magkaibang kabiguan na may tatlong magkaibang may-ari.

Itabi ang log ng script sa tabi ng resulta ng browser sa halip na palitan ang isa ng isa pa. Ang natitirang tanong ay ordinaryong desisyon sa integrasyon: bigyan ang environment na iyon ng access na kailangan nito, o maghatid dito ng kontroladong resulta.