Apps Script VPN દ્વારા તમારી આંતરિક એપ સુધી કેમ પહોંચી શકતું નથી

ડેશબોર્ડ લેપટોપના બ્રાઉઝરમાં બરાબર ખૂલે છે, પણ એ જ સ્પ્રેડશીટ સ્ક્રિપ્ટ સરનામું ઉપલબ્ધ ન હોવાની ભૂલ સાથે નિષ્ફળ જાય છે. VPN ચાલુ કે બંધ કરવાથી કંઈ બદલાતું નથી, કારણ કે વિનંતી લેપટોપમાંથી જ બહાર નીકળતી નથી. Apps Script Google ના ઇન્ફ્રાસ્ટ્રક્ચર પર ચાલે છે અને ત્યાંથી પોતાનું કનેક્શન ખોલે છે. એ એક હકીકત આખી ડિઝાઇન નક્કી કરે છે.

કંઈપણ બદલતા પહેલાં બે પ્રશ્નો અલગ કરો: કઈ મશીન વિનંતી મોકલે છે, અને પ્રાપ્તકર્તા કયો ઓળખપત્ર સ્વીકારે છે.

વિનંતી ક્યારેય તમારા લેપટોપ પર શરૂ થતી નથી

બ્રાઉઝર ટૅબ લેપટોપથી, VPN એડેપ્ટર, આંતરિક DNS પ્રત્યય થઈને ખાનગી સબનેટમાં મોકલે છે. UrlFetchApp Google દ્વારા સંચાલિત હોસ્ટથી મોકલે છે, તેથી તે Google ના રિઝોલ્વર, Google ના એગ્રેસ સરનામાં જુએ છે અને તમારા split-tunnel માર્ગોમાંથી એક પણ જોતું નથી. બંને માર્ગો સ્પ્રેડશીટ દસ્તાવેજ વહેંચે છે, નેટવર્ક સ્થાન નહીં. એપ્લિકેશનના એક્સેસ લોગમાં સ્ક્રિપ્ટનો પ્રયાસ 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 સાઇન-ઇન પૃષ્ઠ એટલે વિનંતી એવા ઇન્ટરેક્ટિવ સ્તરે પહોંચી જે સ્ક્રિપ્ટ પૂરું કરી શકતું નથી. ત્રણ અલગ નિષ્ફળતા, ત્રણ અલગ માલિક.

સ્ક્રિપ્ટનો લોગ બ્રાઉઝરના પરિણામની બાજુમાં રાખો, એકને બીજાથી બદલો નહીં. પછી બાકી પ્રશ્ન સામાન્ય ઇન્ટિગ્રેશન નિર્ણય છે: તે વાતાવરણને જરૂરી એક્સેસ આપો, અથવા તેને નિયંત્રિત પરિણામ પહોંચાડો.