Proč se Apps Script nedostane k vaší interní aplikaci přes VPN

Panel se v prohlížeči na notebooku otevře bez problémů, ale stejný skript tabulky selže s chybou nedostupné adresy. Zapnutí či vypnutí VPN nic nezmění, protože požadavek notebook vůbec neopouští. Apps Script běží v infrastruktuře Google a odtud otevírá vlastní spojení. Tato jediná skutečnost určuje celý návrh.

Než cokoli změníte, oddělte dvě otázky: který stroj požadavek odesílá a jaké přihlašovací údaje přijímá příjemce.

Požadavek nikdy nezačíná na vašem notebooku

Karta prohlížeče odesílá z notebooku, přes adaptér VPN, interní sufix DNS a do privátní podsítě. UrlFetchApp odesílá z hostitele spravovaného Googlem, takže vidí resolvery Google, výstupní adresy Google a žádnou z vašich split-tunnel tras. Obě cesty sdílejí dokument tabulky, ne síťové umístění. V přístupovém logu aplikace se pokus skriptu objeví jako adresa Google, nikoli jako adresa z poolu VPN, což je nejrychlejší potvrzení, které dostanete.

Proto místní opravy nic neřeší. Nasměrování notebooku na jiný resolver, restart klienta VPN nebo přidání záznamu do hosts změní cestu prohlížeče a cestu skriptu nechá přesně tak, jak byla.

Co to vylučuje

Na koncový bod dostupný jen zevnitř se z Apps Scriptu nedostanete a seznam povolených IP je v této pozici slabou náhradou kontroly přístupu. Výstupní rozsahy Google jsou široké, sdílené s dalšími zákazníky a nelze je svázat s jedním skriptem. Reference UrlFetchApp uvádí, že požadavky pocházejí z poolu IP Google, což je autoritativní verze tohoto tvrzení. Otevření interní aplikace těmto rozsahům pustí provoz, který nemůžete připsat.

Relace v prohlížeči se chovají stejně. Cookie nebo relace SSO v prohlížeči notebooku s požadavkem necestuje, protože požadavek je čerstvý klient HTTPS bez stavu relace. Cokoli závisí na přesměrování SSO v prohlížeči, skončí na tomto přesměrování, ne u vašich dat.

Dvě proveditelné podoby

První podoba dává skriptu schválené API. Zveřejněte interní službu za bránou, která ověřuje volajícího, a nechte skript předložit údaj, který brána přijímá, například token servisního účtu. V Apps Scriptu to znamená knihovnu OAuth2 nebo ScriptApp.getOAuthToken(), plus seznam povolených identit volajícího na straně API místo seznamu IP.

Druhá podoba obrací směr. Interní úloha dotazuje privátní systém a publikuje řízený výsledek do Sheetu, objektu Cloud Storage nebo tabulky BigQuery, kterou skript čte. Úloha Cloud Run, místní plánovač nebo existující krok ETL mohou být tou úlohou a žádná z nich nemusí přijímat příchozí spojení. Tabulka pak spotřebovává datovou sadu místo rozhraní.

Která podoba zvítězí, závisí na čerstvosti, kontrole na úrovni polí a na tom, kdo musí moci čtenáře auditovat.

Co musí publikovaný výsledek obsahovat

Tok opačným směrem potřebuje výslovnou smlouvu: pole, která nese, interval obnovy, skupinu čtenářů a co se stane, když interní úloha selže. Bez těch čtyř tabulka tiše ukazuje včerejší čísla. Přidejte generovaný sloupec s časovým razítkem a počet řádků, aby byl zastaralý nebo částečný publikovaný výsledek vidět přímo v tabulce, aniž by někdo otevíral log.

Směr API potřebuje smlouvu také: jaké přihlašovací údaje brána přijímá, jaké scopes token nese a které identity volajícího jsou povoleny. Odpověď 200, která obsahuje přihlašovací stránku, není úspěšné volání, proto kontrolujte tělo, ne jen stavový kód.

Čtěte chybu ze správné strany

Apps Script hlásí nedostupného hostitele jako výjimku nedostupné adresy, což není zpráva prohlížeče o odmítnutém spojení. 403 od brány znamená, že požadavek dorazil a přihlašovací údaj nebo politika byly odmítnuty. HTML přihlašovací stránka znamená, že požadavek dosáhl interaktivní vrstvy, kterou skript nedokončí. Tři různé poruchy se třemi různými vlastníky.

Držte log skriptu vedle výsledku prohlížeče, místo abyste jedno nahrazovali druhým. Zbývající otázka je pak běžné integrační rozhodnutí: dejte tomu prostředí přístup, který potřebuje, nebo mu doručte řízený výsledek.