Apps Script VPN से आपके आंतरिक ऐप तक क्यों नहीं पहुँच सकता

ब्राउज़र में लैपटॉप पर डैशबोर्ड ठीक खुलता है, लेकिन वही स्प्रेडशीट स्क्रिप्ट पता उपलब्ध न होने की त्रुटि के साथ विफल हो जाती है। VPN चालू या बंद करने से कुछ नहीं बदलता, क्योंकि अनुरोध लैपटॉप से ही बाहर नहीं निकलता। Apps Script Google के ढाँचे पर चलता है और वहीं से अपना संबंध खोलता है। यही एक तथ्य पूरा डिज़ाइन तय करता है।

कुछ भी बदलने से पहले दो सवाल अलग करें: कौन-सी मशीन अनुरोध भेजती है, और प्राप्तकर्ता कौन-सा क्रेडेंशियल स्वीकार करता है।

अनुरोध कभी आपके लैपटॉप पर शुरू नहीं होता

ब्राउज़र का टैब लैपटॉप से, VPN एडाप्टर और आंतरिक DNS प्रत्यय से होकर निजी सबनेट में भेजता है। UrlFetchApp Google द्वारा प्रबंधित होस्ट से भेजता है, इसलिए यह Google के रिज़ॉल्वर, Google के एग्रेस पते देखता है और आपके स्प्लिट-टनल मार्गों में से एक भी नहीं देखता। दोनों पथ एक स्प्रेडशीट दस्तावेज़ साझा करते हैं, कोई नेटवर्क स्थान नहीं। ऐप के एक्सेस लॉग में स्क्रिप्ट का प्रयास VPN पूल के पते के बजाय Google पते के रूप में दिखता है, और यही सबसे तेज़ पुष्टि है जो आपको मिलेगी।

इसलिए स्थानीय सुधार कुछ नहीं करते। लैपटॉप को दूसरे रिज़ॉल्वर की ओर इंगित करना, VPN क्लाइंट को फिर से शुरू करना या hosts में प्रविष्टि जोड़ना ब्राउज़र का पथ बदलता है और स्क्रिप्ट का पथ जैसा था वैसा ही छोड़ देता है।

यह किसे बाहर करता है

केवल आंतरिक एंडपॉइंट Apps Script से पहुँच से बाहर है, और इस स्थिति में IP अनुमति-सूची पहुँच नियंत्रण का कमज़ोर विकल्प है। Google के एग्रेस रेंज व्यापक हैं, अन्य ग्राहकों के साथ साझा हैं और एक स्क्रिप्ट से बाँधना असंभव है। UrlFetchApp संदर्भ कहता है कि अनुरोध Google के IP पूल से आते हैं, जो उस दावे का आधिकारिक संस्करण है। आंतरिक ऐप को उन रेंजों के लिए खोलना ऐसा ट्रैफ़िक अंदर आने देता है जिसे आप आरोपित नहीं कर सकते।

ब्राउज़र सत्र भी वैसे ही व्यवहार करते हैं। लैपटॉप के ब्राउज़र में कुकी या 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 साइन-इन पृष्ठ का अर्थ है कि अनुरोध ऐसी इंटरैक्टिव परत तक पहुँचा जिसे स्क्रिप्ट पूरा नहीं कर सकता। तीन अलग विफलताएँ, तीन अलग ज़िम्मेदार।

स्क्रिप्ट का लॉग ब्राउज़र के परिणाम के बगल में रखें, एक को दूसरे से बदलें नहीं। तब बचा सवाल सामान्य एकीकरण निर्णय है: उस वातावरण को ज़रूरी पहुँच दें, या उसे नियंत्रित परिणाम सौंपें।