Miért nem éri el egy Apps Script a belső alkalmazásodat VPN-en keresztül

Az irányítópult szépen megnyílik a laptop böngészőjében, de ugyanaz a táblázat-szkript cím elérhetetlenségét jelző hibával elhasal. A VPN be- vagy kikapcsolása semmit sem változtat, mert a kérés egyáltalán nem hagyja el a laptopot. Az Apps Script a Google infrastruktúráján fut, és onnan nyit saját kapcsolatot. Ez az egyetlen tény határozza meg a teljes tervezést.

Két kérdést válassz szét, mielőtt bármit módosítasz: melyik gép küldi a kérést, és milyen hitelesítő adatot fogad el a fogadó.

A kérés soha nem a laptopodon indul

Egy böngészőfül a laptopról küld, a VPN-adapteren, a belső DNS-utótagon át a privát alhálózatba. Az UrlFetchApp egy Google által kezelt hosztról küld, így a Google feloldóit, a Google kimenő címeit látja, és a split-tunnel útvonalaid közül egyiket sem. A két útvonal egy táblázatdokumentumot oszt meg, nem egy hálózati helyet. Az alkalmazás hozzáférési naplójában a szkript kísérlete Google-címként jelenik meg, nem VPN-pool címként, és ez a leggyorsabb megerősítés, amit kaphatsz.

Ezért a helyi javítások semmit sem tesznek. A laptop másik feloldóra állítása, a VPN-kliens újraindítása vagy egy hosts-bejegyzés hozzáadása a böngésző útvonalát változtatja meg, a szkript útvonalát pedig pontosan úgy hagyja, ahogy volt.

Mit zár ki ez

Csak belső végpontot Apps Scriptből nem lehet elérni, és az IP-engedélylista ebben a helyzetben gyenge helyettesítője a hozzáférés-vezérlésnek. A Google kimenő tartományai szélesek, más ügyfelekkel megosztottak, és nem köthetők egyetlen szkripthez. Az UrlFetchApp-referencia szerint a kérések a Google IP-pooljából származnak, ami ezen állítás mérvadó változata. A belső alkalmazás megnyitása ezekre a tartományokra olyan forgalmat enged be, amelyet nem tudsz hozzárendelni.

A böngésző-munkamenetek ugyanígy viselkednek. A laptop böngészőjében lévő cookie vagy SSO-munkamenet nem utazik a kéréssel, amely munkamenet-állapot nélküli, friss HTTPS-kliens. Minden, ami a böngésző SSO-átirányításától függ, annál az átirányításnál ér véget, nem az adataidnál.

Két járható forma

Az első forma jóváhagyott API-t ad a szkriptnek. Tedd közzé a belső szolgáltatást egy olyan átjáró mögött, amely hitelesíti a hívót, majd a szkript olyan hitelesítő adatot mutasson be, amelyet az átjáró elfogad, például szolgáltatásfiók-tokent. Az Apps Scriptben ez OAuth2-könyvtárat vagy ScriptApp.getOAuthToken() hívást jelent, valamint a hívói identitások engedélylistáját az API oldalán IP-lista helyett.

A második forma megfordítja az irányt. Egy belső feladat lekérdezi a privát rendszert, és ellenőrzött eredményt tesz közzé egy Sheetben, egy Cloud Storage-objektumban vagy egy BigQuery-táblában, amelyet a szkript olvas. Cloud Run-feladat, helyi ütemező vagy meglévő ETL-lépés is lehet ez a feladat, és egyiküknek sem kell bejövő kapcsolatot fogadnia. A táblázat ezután adathalmazt fogyaszt interfész helyett.

Melyik forma nyer, a frissességtől, a mezőszintű vezérléstől és attól függ, kinek kell tudnia auditálni az olvasót.

Mit kell tartalmaznia a közzétett eredménynek

A fordított irányú hírfolyamhoz kifejezett szerződés kell: a szállított mezők, a frissítési intervallum, az olvasói csoport és az, hogy mi történik, ha a belső feladat elbukik. E négy nélkül a táblázat csendesen a tegnapi számokat mutatja. Adj hozzá generált időbélyeg-oszlopot és sorszámot, hogy az elavult vagy részleges közzététel magában a táblázatban látszódjon, anélkül hogy bárki naplót nyitna.

Az API-irányhoz is szerződés kell: milyen hitelesítő adatot fogad el az átjáró, milyen scopes-t hordoz a token, és mely hívói identitások engedélyezettek. Egy 200-as válasz, amely bejelentkező oldalt tartalmaz, nem sikeres hívás, ezért a törzset is ellenőrizd, ne csak az állapotkódot.

A hibát a megfelelő oldalról olvasd

Az Apps Script az elérhetetlen hostot cím-elérhetetlenségi kivételként jelenti, ami nem a böngésző kapcsolat-visszautasítás üzenete. Az átjáró 403-a azt jelenti, hogy a kérés megérkezett, és egy hitelesítő adatot vagy szabályzatot visszautasítottak. Egy HTML bejelentkező oldal azt jelenti, hogy a kérés olyan interaktív réteget ért el, amelyet egy szkript nem tud befejezni. Három különböző hiba, három különböző felelőssel.

Tartsd a szkript naplóját a böngésző eredménye mellett, ahelyett hogy az egyiket a másikkal helyettesítenéd. A fennmaradó kérdés ekkor szokásos integrációs döntés: add meg annak a környezetnek a szükséges hozzáférést, vagy szállíts neki ellenőrzött eredményt.