למה Apps Script לא מגיע לאפליקציה הפנימית שלכם דרך VPN

לוח הבקרה נפתח היטב בדפדפן במחשב הנייד, אבל אותו סקריפט גיליון נכשל עם שגיאת כתובת לא זמינה. הפעלה או כיבוי של ה-VPN לא משנים דבר, כי הבקשה בכלל לא יוצאת מהמחשב הנייד. Apps Script פועל בתשתית של Google ופותח שם חיבור משלו. העובדה האחת הזו קובעת את כל התכנון.

הפרידו שתי שאלות לפני שמשנים משהו: איזו מכונה שולחת את הבקשה, ואיזה אישור מקבל הצד המקבל.

הבקשה אף פעם לא מתחילה במחשב הנייד שלכם

לשונית דפדפן שולחת מהמחשב הנייד, דרך מתאם ה-VPN, סיומת ה-DNS הפנימית ואל תת-הרשת הפרטית. UrlFetchApp שולח ממארח שמנוהל על ידי Google, ולכן הוא רואה את מפענחי השמות של Google, את כתובות היציאה של Google ואף אחד מנתיבי ה-split-tunnel שלכם. שני הנתיבים חולקים מסמך גיליון, לא מיקום רשת. ביומן הגישה של האפליקציה, הניסיון של הסקריפט מופיע ככתובת Google ולא ככתובת ממאגר ה-VPN, וזה האישור המהיר ביותר שתקבלו.

לכן תיקונים מקומיים לא עושים דבר. הפניית המחשב הנייד למפענח אחר, הפעלה מחדש של לקוח ה-VPN או הוספת רשומה ב-hosts משנה את הנתיב של הדפדפן ומשאירה את הנתיב של הסקריפט בדיוק כפי שהיה.

מה זה שולל

נקודת קצה פנימית בלבד אינה נגישה מ-Apps Script, ורשימת כתובות IP מורשות היא תחליף חלש לבקרת גישה בעמדה הזו. טווחי היציאה של Google רחבים, משותפים עם לקוחות אחרים ואי אפשר לקשור אותם לסקריפט אחד. התיעוד של UrlFetchApp קובע שהבקשות מגיעות ממאגר כתובות ה-IP של Google, וזו הגרסה המוסמכת של הטענה הזו. פתיחת האפליקציה הפנימית לטווחים האלה מכניסה תעבורה שאי אפשר לייחס.

הפעלות דפדפן מתנהגות באותה דרך. קוקי או הפעלת SSO בדפדפן של המחשב הנייד לא נוסעים עם הבקשה, שהיא לקוח HTTPS חדש בלי מצב הפעלה. כל מה שתלוי בהפניה חוזרת של SSO בדפדפן מסתיים בהפניה הזו ולא בנתונים שלכם.

שתי צורות מעשיות

הצורה הראשונה נותנת לסקריפט API מאושר. פרסמו את השירות הפנימי מאחורי שער שמאמת את הקורא, ואז תנו לסקריפט להציג אישור שהשער מקבל, כמו אסימון של חשבון שירות. ב-Apps Script זה אומר ספריית OAuth2 או ScriptApp.getOAuthToken(), יחד עם רשימת זהויות קורא מורשות בצד ה-API במקום רשימת IP.

הצורה השנייה הופכת את הכיוון. משימה פנימית שואלת את המערכת הפרטית ומפרסמת תוצאה מבוקרת ל-Sheet, לאובייקט Cloud Storage או לטבלת BigQuery שהסקריפט קורא. משימת Cloud Run, מתזמן מקומי או שלב ETL קיים יכולים כולם להיות המשימה הזו, ואף אחד מהם לא צריך לקבל חיבור נכנס. הגיליון צורך אז מערך נתונים במקום ממשק.

איזו צורה תנצח תלוי בטריות, בשליטה ברמת השדה ובמי שצריך להיות מסוגל לבקר את הקורא.

מה התוצאה המפורסמת חייבת להכיל

הזנה בכיוון ההפוך צריכה חוזה מפורש: השדות שהיא נושאת, מרווח הרענון, קבוצת הקוראים ומה קורה כשהמשימה הפנימית נכשלת. בלי ארבעת אלה הגיליון מציג בשקט את המספרים של אתמול. הוסיפו עמודת חותם זמן שנוצרת וספירת שורות כדי שפרסום מיושן או חלקי יהיה גלוי בגיליון עצמו, בלי שמישהו יפתח יומן.

כיוון ה-API צריך גם חוזה: איזה אישור השער מקבל, אילו scopes נושאת האסימון ואילו זהויות קורא מורשות. תשובה 200 שמכילה עמוד כניסה אינה קריאה מוצלחת, לכן בדקו את הגוף ולא רק את קוד המצב.

קראו את השגיאה מהצד הנכון

Apps Script מדווח על מארח לא נגיש כחריגה של כתובת לא זמינה, וזו לא הודעת החיבור הנדחה של הדפדפן. 403 מהשער אומר שהבקשה הגיעה ושהאישור או המדיניות נדחו. עמוד כניסה ב-HTML אומר שהבקשה הגיעה לשכבה אינטראקטיבית שסקריפט לא יכול להשלים. שלושה כשלים שונים עם שלושה בעלים שונים.

החזיקו את יומן הסקריפט לצד התוצאה של הדפדפן במקום להחליף אחד בשני. השאלה שנותרה היא אז החלטת אינטגרציה רגילה: לתת לסביבה הזו את הגישה שהיא צריכה, או לספק לה תוצאה מבוקרת.