কেন 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 সাইন-ইন পৃষ্ঠা মানে অনুরোধ এমন একটি ইন্টারঅ্যাকটিভ স্তরে পৌঁছেছে যা স্ক্রিপ্ট সম্পূর্ণ করতে পারে না। তিনটি ভিন্ন ব্যর্থতা, তিনজন ভিন্ন মালিক।

ব্রাউজারের ফলাফলের পাশে স্ক্রিপ্টের লগ রাখুন, একটিকে অন্যটি দিয়ে প্রতিস্থাপন করবেন না। তখন বাকি প্রশ্নটি সাধারণ ইন্টিগ্রেশন সিদ্ধান্ত: ওই পরিবেশকে প্রয়োজনীয় অ্যাক্সেস দিন, বা তাকে একটি নিয়ন্ত্রিত ফলাফল পৌঁছে দিন।