De ce un Apps Script nu ajunge la aplicația ta internă prin VPN

Panoul se deschide bine în browserul de pe laptop, dar același script de foaie de calcul eșuează cu o eroare de adresă indisponibilă. Pornirea sau oprirea VPN-ului nu schimbă nimic, pentru că cererea nu părăsește niciodată laptopul. Apps Script rulează pe infrastructura Google și își deschide propria conexiune de acolo. Acest singur fapt decide întregul design.

Separă două întrebări înainte de a schimba ceva: ce mașină trimite cererea și ce acreditare acceptă destinatarul.

Cererea nu începe niciodată pe laptopul tău

Un tab de browser trimite de pe laptop, prin adaptorul VPN, sufixul DNS intern și în subrețeaua privată. UrlFetchApp trimite de pe un host administrat de Google, așa că vede resolverele Google, adresele de ieșire Google și niciuna dintre rutele tale split-tunnel. Cele două căi partajează un document de foaie de calcul, nu o locație de rețea. În jurnalul de acces al aplicației, încercarea scriptului apare ca o adresă Google în loc de o adresă din pool-ul VPN, și aceasta este cea mai rapidă confirmare pe care o vei obține.

De aceea corecțiile locale nu fac nimic. Îndreptarea laptopului către alt resolver, repornirea clientului VPN sau adăugarea unei intrări în hosts schimbă calea browserului și lasă calea scriptului exact cum era.

Ce exclude asta

Un endpoint doar intern nu poate fi atins din Apps Script, iar lista de IP-uri permise este un substitut slab pentru controlul accesului în această poziție. Intervalele de ieșire ale Google sunt largi, partajate cu alți clienți și imposibil de legat de un singur script. Referința UrlFetchApp arată că cererile provin din pool-ul de IP-uri al Google, ceea ce este versiunea autorizată a acelei afirmații. Deschiderea aplicației interne către acele intervale admite trafic pe care nu îl poți atribui.

Sesiunile de browser se comportă la fel. Un cookie sau o sesiune SSO din browserul laptopului nu călătorește cu cererea, care este un client HTTPS nou fără stare de sesiune. Tot ce depinde de o redirecționare SSO a browserului se termină la acea redirecționare, nu la datele tale.

Două forme viabile

Prima formă îi dă scriptului un API aprobat. Publică serviciul intern în spatele unei porți care autentifică apelantul, apoi lasă scriptul să prezinte o acreditare pe care poarta o acceptă, cum ar fi un token de cont de serviciu. În Apps Script asta înseamnă o bibliotecă OAuth2 sau ScriptApp.getOAuthToken(), plus o listă de identități de apelant permise pe partea de API în loc de o listă de IP-uri.

A doua formă inversează direcția. Un job intern interoghează sistemul privat și publică un rezultat controlat într-un Sheet, într-un obiect Cloud Storage sau într-un tabel BigQuery pe care scriptul îl citește. Un job Cloud Run, un planificator local sau un pas ETL existent pot fi toate acel job, și niciunul nu trebuie să accepte o conexiune de intrare. Foaia consumă atunci un set de date în loc de o interfață.

Care formă câștigă depinde de prospețime, de controlul la nivel de câmp și de cine trebuie să poată audita cititorul.

Ce trebuie să conțină rezultatul publicat

Un flux în direcție inversă are nevoie de un contract explicit: câmpurile pe care le transportă, intervalul de reîmprospătare, grupul de cititori și ce se întâmplă când jobul intern eșuează. Fără acele patru, foaia arată în liniște cifrele de ieri. Adaugă o coloană de marcă temporală generată și un număr de rânduri, astfel încât o publicare învechită sau parțială să fie vizibilă în foaia însăși, fără ca cineva să deschidă un jurnal.

Direcția API are nevoie și ea de un contract: ce acreditare acceptă poarta, ce scopuri poartă tokenul și ce identități de apelant sunt permise. Un răspuns 200 care conține o pagină de autentificare nu este un apel reușit, așa că verifică corpul și nu doar codul de stare.

Citește eroarea din partea corectă

Apps Script raportează un host inaccesibil ca excepție de adresă indisponibilă, care nu este mesajul browserului despre conexiune refuzată. Un 403 de la poartă înseamnă că cererea a ajuns și că o acreditare sau o politică a fost respinsă. O pagină de autentificare HTML înseamnă că cererea a atins un strat interactiv pe care un script nu îl poate finaliza. Trei eșecuri diferite cu trei responsabili diferiți.

Ține jurnalul scriptului lângă rezultatul browserului în loc să înlocuiești unul cu altul. Întrebarea rămasă este atunci o decizie obișnuită de integrare: dă acelui mediu accesul de care are nevoie sau livrează-i un rezultat controlat.