Dlaczego Apps Script nie dociera do Twojej aplikacji wewnętrznej przez VPN

Panel otwiera się bez problemu w przeglądarce na laptopie, ale ten sam skrypt arkusza kalkulacyjnego zawodzi z błędem niedostępnego adresu. Włączanie i wyłączanie VPN niczego nie zmienia, bo żądanie w ogóle nie opuszcza laptopa. Apps Script wykonuje się w infrastrukturze Google i stamtąd otwiera własne połączenie. Ten jeden fakt decyduje o całym projekcie.

Rozdziel dwa pytania, zanim cokolwiek zmienisz: która maszyna wysyła żądanie i jakie poświadczenia akceptuje odbiorca.

Żądanie nigdy nie zaczyna się na Twoim laptopie

Karta przeglądarki wysyła z laptopa, przez adapter VPN, wewnętrzny sufiks DNS i do prywatnej podsieci. UrlFetchApp wysyła z hosta zarządzanego przez Google, więc widzi resolver Google, adresy wyjściowe Google i żadnej z Twoich tras split-tunnel. Obie ścieżki dzielą dokument arkusza, a nie lokalizację w sieci. W dzienniku dostępu aplikacji próba skryptu pojawia się jako adres Google, a nie adres z puli VPN, i to najszybsze potwierdzenie, jakie otrzymasz.

Dlatego lokalne poprawki nic nie dają. Wskazanie laptopowi innego resolvera, ponowne uruchomienie klienta VPN lub dodanie wpisu w hosts zmienia ścieżkę przeglądarki, a ścieżkę skryptu zostawia dokładnie taką, jaka była.

Co to wyklucza

Do punktu końcowego dostępnego tylko wewnętrznie nie da się dotrzeć z Apps Script, a lista dozwolonych adresów IP jest w tym miejscu słabym zamiennikiem kontroli dostępu. Zakresy wyjściowe Google są szerokie, współdzielone z innymi klientami i niemożliwe do przypisania do jednego skryptu. Dokumentacja UrlFetchApp podaje, że żądania pochodzą z puli adresów IP Google, co jest miarodajną wersją tego twierdzenia. Otwarcie wewnętrznej aplikacji na te zakresy wpuszcza ruch, którego nie możesz przypisać.

Sesje przeglądarki zachowują się tak samo. Plik cookie lub sesja SSO w przeglądarce laptopa nie podróżuje z żądaniem, które jest nowym klientem HTTPS bez stanu sesji. Wszystko, co zależy od przekierowania SSO w przeglądarce, kończy się na tym przekierowaniu, a nie na Twoich danych.

Dwa wykonalne kształty

Pierwszy kształt daje skryptowi zatwierdzone API. Opublikuj wewnętrzną usługę za bramą, która uwierzytelnia wywołującego, a następnie pozwól skryptowi przedstawić poświadczenie akceptowane przez bramę, na przykład token konta usługi. W Apps Script oznacza to bibliotekę OAuth2 lub ScriptApp.getOAuthToken(), plus listę dozwolonych tożsamości wywołującego po stronie API zamiast listy adresów IP.

Drugi kształt odwraca kierunek. Wewnętrzne zadanie odpytuje prywatny system i publikuje kontrolowany wynik w Sheet, obiekcie Cloud Storage lub tabeli BigQuery, którą skrypt czyta. Zadanie Cloud Run, lokalny harmonogram lub istniejący krok ETL mogą być tym zadaniem, i żadne z nich nie musi przyjmować połączenia przychodzącego. Arkusz konsumuje wtedy zbiór danych zamiast interfejsu.

Który kształt wygrywa, zależy od świeżości, kontroli na poziomie pól i od tego, kto musi móc audytować czytelnika.

Co musi zawierać opublikowany wynik

Strumień w kierunku odwrotnym potrzebuje wyraźnej umowy: pól, które niesie, interwału odświeżania, grupy czytelników i tego, co się dzieje, gdy wewnętrzne zadanie zawiedzie. Bez tych czterech arkusz po cichu pokazuje wczorajsze liczby. Dodaj wygenerowaną kolumnę znacznika czasu i liczbę wierszy, aby nieaktualna lub częściowa publikacja była widoczna w samym arkuszu, bez otwierania dziennika.

Kierunek API też potrzebuje umowy: jakie poświadczenie akceptuje brama, jakie scopes niesie token i które tożsamości wywołującego są dozwolone. Odpowiedź 200 zawierająca stronę logowania nie jest udanym wywołaniem, więc sprawdzaj treść, a nie tylko kod stanu.

Czytaj błąd z właściwej strony

Apps Script zgłasza nieosiągalny host jako wyjątek niedostępnego adresu, co nie jest komunikatem przeglądarki o odrzuconym połączeniu. 403 od bramy oznacza, że żądanie dotarło i odrzucono poświadczenie lub politykę. Strona logowania HTML oznacza, że żądanie dotarło do warstwy interaktywnej, której skrypt nie może ukończyć. Trzy różne awarie z trzema różnymi właścicielami.

Trzymaj dziennik skryptu obok wyniku przeglądarki, zamiast zastępować jedno drugim. Pozostałe pytanie to wtedy zwykła decyzja integracyjna: dać temu środowisku potrzebny dostęp albo dostarczyć mu kontrolowany wynik.