Warum ein Apps Script Ihre interne App über VPN nicht erreicht

Das Dashboard öffnet sich im Browser auf dem Laptop einwandfrei, doch dasselbe Tabellenkalkulationsskript scheitert mit einem Fehler zur nicht verfügbaren Adresse. Das Ein- und Ausschalten der VPN ändert nichts, weil die Anfrage den Laptop überhaupt nicht verlässt. Apps Script läuft auf Googles Infrastruktur und öffnet von dort seine eigene Verbindung. Diese eine Tatsache entscheidet das gesamte Design.

Trennen Sie zwei Fragen, bevor Sie etwas ändern: Welche Maschine sendet die Anfrage, und welche Anmeldedaten akzeptiert der Empfänger.

Die Anfrage beginnt nie auf Ihrem Laptop

Ein Browser-Tab sendet vom Laptop, durch den VPN-Adapter, das interne DNS-Suffix und in das private Subnetz. UrlFetchApp sendet von einem von Google verwalteten Host, sieht also Googles Resolver, Googles Egress-Adressen und keine Ihrer Split-Tunneling-Routen. Die beiden Pfade teilen ein Tabellendokument, keinen Netzwerkstandort. Im Zugriffsprotokoll der Anwendung erscheint der Versuch des Skripts als Google-Adresse statt als Adresse aus dem VPN-Pool, und das ist die schnellste Bestätigung, die Sie bekommen.

Deshalb bewirken lokale Korrekturen nichts. Den Laptop auf einen anderen Resolver zu zeigen, den VPN-Client neu zu starten oder einen hosts-Eintrag hinzuzufügen ändert den Pfad des Browsers und lässt den Pfad des Skripts genau so, wie er war.

Was das ausschließt

Ein rein interner Endpunkt ist von Apps Script nicht erreichbar, und eine IP-Allowlist ist an dieser Stelle ein schwacher Ersatz für Zugriffskontrolle. Googles Egress-Bereiche sind breit, werden mit anderen Kunden geteilt und lassen sich nicht an ein Skript binden. Die UrlFetchApp-Referenz gibt an, dass Anfragen aus Googles IP-Pool stammen, was die maßgebliche Fassung dieser Aussage ist. Die interne App für diese Bereiche zu öffnen, lässt Verkehr herein, den Sie nicht zuordnen können.

Browsersitzungen verhalten sich genauso. Ein Cookie oder eine SSO-Sitzung im Browser des Laptops reist nicht mit der Anfrage, die ein frischer HTTPS-Client ohne Sitzungszustand ist. Alles, was von einer SSO-Weiterleitung im Browser abhängt, endet an dieser Weiterleitung statt an Ihren Daten.

Zwei gangbare Formen

Die erste Form gibt dem Skript eine genehmigte API. Veröffentlichen Sie den internen Dienst hinter einem Gateway, das den Aufrufer authentifiziert, und lassen Sie das Skript dann einen Nachweis vorlegen, den das Gateway akzeptiert, etwa ein Dienstkonto-Token. In Apps Script bedeutet das eine OAuth2-Bibliothek oder ScriptApp.getOAuthToken(), dazu eine Allowlist der Aufruferidentitäten auf der API-Seite statt einer IP-Allowlist.

Die zweite Form kehrt die Richtung um. Ein interner Job fragt das private System ab und veröffentlicht ein kontrolliertes Ergebnis in einem Sheet, einem Cloud Storage-Objekt oder einer BigQuery-Tabelle, die das Skript liest. Ein Cloud Run-Job, ein lokaler Scheduler oder ein bestehender ETL-Schritt können alle dieser Job sein, und keiner von ihnen muss eine eingehende Verbindung annehmen. Die Tabelle konsumiert dann einen Datensatz statt einer Schnittstelle.

Welche Form gewinnt, hängt von Aktualität, Kontrolle auf Feldebene und davon ab, wer den Leser prüfen können muss.

Was das veröffentlichte Ergebnis enthalten muss

Ein rückwärts gerichteter Feed braucht einen ausdrücklichen Vertrag: die Felder, die er trägt, das Aktualisierungsintervall, die Lesergruppe und was passiert, wenn der interne Job scheitert. Ohne diese vier zeigt die Tabelle stillschweigend die Zahlen von gestern. Fügen Sie eine erzeugte Zeitstempelspalte und eine Zeilenanzahl hinzu, damit eine veraltete oder teilweise Veröffentlichung in der Tabelle selbst sichtbar ist, ohne dass jemand ein Protokoll öffnet.

Die API-Richtung braucht ebenfalls einen Vertrag: welche Anmeldedaten das Gateway akzeptiert, welche Scopes das Token trägt und welche Aufruferidentitäten erlaubt sind. Eine 200-Antwort, die eine Anmeldeseite enthält, ist kein erfolgreicher Aufruf, prüfen Sie also den Body und nicht nur den Statuscode.

Lesen Sie den Fehler von der richtigen Seite

Apps Script meldet einen nicht erreichbaren Host als Ausnahme zur nicht verfügbaren Adresse, was nicht die Meldung des Browsers über eine abgelehnte Verbindung ist. Ein 403 vom Gateway bedeutet, dass die Anfrage ankam und ein Anmeldedatum oder eine Richtlinie abgelehnt wurde. Eine HTML-Anmeldeseite bedeutet, dass die Anfrage eine interaktive Schicht erreichte, die ein Skript nicht abschließen kann. Drei verschiedene Fehler mit drei verschiedenen Verantwortlichen.

Halten Sie das Protokoll des Skripts neben dem Ergebnis des Browsers, statt eines durch das andere zu ersetzen. Die verbleibende Frage ist dann eine gewöhnliche Integrationsentscheidung: Geben Sie dieser Umgebung den Zugriff, den sie braucht, oder liefern Sie ihr ein kontrolliertes Ergebnis.