Чому 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, і це авторитетна версія такого твердження. Відкриття внутрішнього застосунку для цих діапазонів пропускає трафік, який ви не можете атрибутувати.

Сеанси браузера поводяться так само. Файл cookie або сеанс 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-сторінка входу означає, що запит досяг інтерактивного шару, який скрипт не може завершити. Три різні збої з трьома різними відповідальними.

Тримайте журнал скрипта поруч із результатом браузера, а не замінюйте одне одним. Питання, що залишається, тоді є звичайним рішенням про інтеграцію: дати цьому середовищу потрібний доступ або доставити йому контрольований результат.