Защо Apps Script не може да достигне вътрешното ви приложение през VPN

Таблото се отваря без проблем в браузъра на лаптопа, а същият скрипт за електронна таблица се проваля с грешка за недостъпен адрес. Включването и изключването на VPN не променя нищо, защото заявката изобщо не напуска лаптопа. Apps Script се изпълнява в инфраструктурата на Google и отваря собствена връзка оттам. Този единствен факт определя целия дизайн.

Разделете два въпроса, преди да промените нещо: коя машина изпраща заявката и какви идентификационни данни приема получателят.

Заявката никога не започва на вашия лаптоп

Разделът на браузъра изпраща от лаптопа, през VPN адаптера, вътрешния DNS суфикс и в частната подмрежа. UrlFetchApp изпраща от хост, управляван от Google, затова той вижда резолверите на Google, изходящите адреси на Google и нито един от вашите split-tunnel маршрути. Двата пътя споделят документ в таблица, а не мрежово място. В журнала за достъп на приложението опитът на скрипта изглежда като адрес на Google, а не като адрес от VPN пул, и това е най-бързото потвърждение, което ще получите.

Затова локалните поправки не правят нищо. Насочването на лаптопа към друг резолвер, рестартирането на VPN клиента или добавянето на запис в hosts променя пътя на браузъра и оставя пътя на скрипта точно какъвто е бил.

Какво изключва това

До крайна точка, достъпна само отвътре, не се стига от Apps Script, а списъкът с разрешени IP адреси е слаб заместител на контрола за достъп на това място. Изходящите диапазони на Google са широки, споделени с други клиенти и не могат да бъдат обвързани с един скрипт. Справката за UrlFetchApp посочва, че заявките произхождат от IP пула на Google, което е авторитетната версия на това твърдение. Отварянето на вътрешното приложение за тези диапазони допуска трафик, който не можете да припишете.

Сесиите в браузъра се държат по същия начин. Бисквитка или SSO сесия в браузъра на лаптопа не пътува със заявката, която е нов HTTPS клиент без състояние на сесия. Всичко, което зависи от SSO пренасочване в браузъра, завършва на това пренасочване, а не при вашите данни.

Две работещи форми

Първата форма дава на скрипта одобрен API. Публикувайте вътрешната услуга зад шлюз, който удостоверява извикващия, и след това накарайте скрипта да представи идентификационни данни, които шлюзът приема, например токен за сервизен акаунт. В Apps Script това означава библиотека OAuth2 или ScriptApp.getOAuthToken(), плюс списък с разрешени самоличности на извикващия от страната на API вместо списък с IP адреси.

Втората форма обръща посоката. Вътрешна задача прави заявка към частната система и публикува контролиран резултат в Sheet, обект в Cloud Storage или таблица в BigQuery, която скриптът чете. Задача в Cloud Run, локален планировчик или съществуваща стъпка ETL могат да бъдат тази задача и нито една от тях не трябва да приема входяща връзка. Тогава таблицата консумира набор от данни вместо интерфейс.

Коя форма печели зависи от свежестта, контрола на ниво поле и кой трябва да може да одитира читателя.

Какво трябва да съдържа публикуваният резултат

Потокът в обратна посока се нуждае от ясен договор: полетата, които носи, интервалът на обновяване, групата читатели и какво се случва, когато вътрешната задача се провали. Без тези четири таблицата тихо показва вчерашните числа. Добавете генерирана колона с времева марка и брой редове, за да е видимо застаряло или частично публикуване в самата таблица, без някой да отваря журнал.

Посоката на API също се нуждае от договор: какви идентификационни данни приема шлюзът, какви scopes носи токенът и кои самоличности на извикващия са разрешени. Отговор 200, който съдържа страница за вход, не е успешно извикване, затова проверявайте тялото, а не само кода на състоянието.

Четете грешката от правилната страна

Apps Script съобщава за недостъпен хост като изключение за недостъпност на адреса, което не е съобщението на браузъра за отказана връзка. 403 от шлюза означава, че заявката е пристигнала и идентификационни данни или политика са били отхвърлени. HTML страница за вход означава, че заявката е достигнала интерактивен слой, който скриптът не може да завърши. Три различни провала с три различни собственика.

Дръжте журнала на скрипта до резултата на браузъра, вместо да заменяте едното с другото. Останалият въпрос тогава е обикновено интеграционно решение: дайте на тази среда достъпа, който ѝ трябва, или ѝ доставете контролиран резултат.