Зашто Apps Script не може да стигне вашу интерну апликацију преко VPN-а

Контролна табла се добро отвара у прегледачу на преносном рачунару, али иста скрипта за табелу не успева са грешком недоступне адресе. Укључивање или искључивање VPN-а ништа не мења, јер захтев уопште не напушта преносни рачунар. Apps Script се извршава на Google инфраструктури и одатле отвара сопствену везу. Та једна чињеница одређује цео дизајн.

Одвојте два питања пре него што било шта промените: која машина шаље захтев и које акредитиве прихвата прималац.

Захтев никада не почиње на вашем преносном рачунару

Језичак прегледача шаље са преносног рачунара, кроз VPN адаптер, интерни DNS суфикс и у приватну подмрежу. UrlFetchApp шаље са hosta којим управља Google, зато види Google ресолвере, Google излазне адресе и ниједну од ваших split-tunnel рута. Две путање деле документ табеле, а не мрежну локацију. У дневнику приступа апликације, покушај скрипте се појављује као Google адреса, а не као адреса из VPN пула, и то је најбрза потврда коју ћете добити.

Зато локалне поправке не раде ништа. Усмеравање преносног рачунара на други ресолвер, поновно покретање VPN клијента или додавање уноса у hosts мења путању прегледача, а путању скрипте оставља тачно каква је била.

Шта то искључује

До крајње тачке доступне само изнутра не може се стићи из Apps Script-а, а листа дозвољених IP адреса је на овом месту слаба замена за контролу приступа. Google излазни опсези су широки, деле се са другим клијентима и немогуће их је везати за једну скрипту. Референца за UrlFetchApp наводи да захтеви потичу из Google IP пула, што је меродавна верзија те тврдње. Отварање интерне апликације тим опсезима пушта саобраћај који не можете да припишете.

Сесије прегледача се понашају исто. Колачић или SSO сесија у прегледачу преносног рачунара не путује са захтевом, који је нови HTTPS клијент без стања сесије. Све што зависи од SSO преусмеравања у прегледачу завршава на том преусмеравању, а не на вашим подацима.

Два изводљива облика

Први облик даје скрипти одобрени API. Објавите интерну услугу иза капије која проверава идентитет позиваоца, а затим нека скрипта представи акредитив који капија прихвата, попут токена сервисног налога. У Apps Script-у то значи библиотеку OAuth2 или ScriptApp.getOAuthToken(), уз листу дозвољених идентитета позиваоца на страни API-ја уместо листе IP адреса.

Други облик окреће смер. Интерни посао шаље упит приватном систему и објављује контролисани резултат у Sheet, објекат Cloud Storage-а или табелу BigQuery-ја коју скрипта чита. Cloud Run посао, локални планер или постојећи ETL корак могу бити тај посао и ниједан од њих не мора да прихвати долазну везу. Табела тада троши скуп података уместо интерфејса.

Који облик побеђује зависи од свежине, контроле на нивоу поља и од тога ко мора да може да ревидира читаоца.

Шта објављени резултат мора да садржи

Ток у обрнутом смеру захтева изричит уговор: поља која носи, интервал освежавања, групу читалаца и шта се дешава када интерни посао не успе. Без тих четири табела тихо приказује јучерашње бројке. Додајте генерисану колону временске ознаке и број редова како би застарело или делимично објављивање било видљиво у самој табели, без да ико отвара дневник.

Смер API-ја такође захтева уговор: које акредитиве капија прихвата, које scopes носи токен и који су идентитети позиваоца дозвољени. Одговор 200 који садржи страницу за пријаву није успешан позив, зато проверите тело, а не само код статуса.

Читајте грешку са праве стране

Apps Script пријављује недоступни host као изузетак недоступне адресе, што није порука прегледача о одбијеној вези. 403 од капије значи да је захтев стигао и да су акредитиви или правило одбијени. HTML страница за пријаву значи да је захтев стигао до интерактивног слоја који скрипта не може да доврши. Три различите грешке са три различита одговорна.

Држите дневник скрипте поред резултата прегледача уместо да једно замењујете другим. Преостало питање је тада уобичајена интеграцијска одлука: дајте том окружењу приступ који му је потребан или му доставите контролисани резултат.