VPN মাঝপথে বন্ধ: পেছনের অনুরোধগুলো কি এখনও বের হচ্ছে?

ট্যাবটি এখনও টানেল মরে যাওয়ার আগের ড্যাশবোর্ড দেখাচ্ছে। স্ট্যাটাসের সংখ্যাগুলো জমে যায়, ছোট একটি স্পিনার ঘুরতে থাকে, আর অ্যাড্রেস বার এখনও এক ঘণ্টা আগে খোলা অ্যাপটি বহন করছে। বিচ্ছেদের পরে আপনি কিছুই ছুঁননি, তবুও পৃষ্ঠাটি হয়তো এখনও নিজের সময়সূচি অনুযায়ী তার সার্ভারে পৌঁছানোর চেষ্টা করছে। এটাই মানুষ মিস করে: কেবল দৃশ্যমান একটি পৃষ্ঠা আর এখনও অনুরোধ পাঠাচ্ছে এমন একটি পৃষ্ঠা বাইরে থেকে একই রকম দেখায়, এবং তাদের মধ্যে কেবল একটি নেটওয়ার্ক লগে দেখা যায়।

একটি পৃষ্ঠা আপনার ছাড়াই যে কাজ শুরু করে

চারটি প্রক্রিয়া লোড করা নথিকে ব্যস্ত রাখে। একটি পুনরাবৃত্ত টাইমার প্রতি কয়েক সেকেন্ডে একটি স্ট্যাটাস কল আবার চালাতে পারে। আপনি ফিরে যাওয়ার পরে ট্যাবটি আবার দৃশ্যমান হলে একটি fetch কাজে লাগতে পারে। WebSocket বা সার্ভার-প্রেরিত ইভেন্টের উপর গড়া একটি লাইভ চ্যানেল নিজের ব্যাকঅফ সময়সূচি অনুযায়ী পুনঃসংযোগের চেষ্টা করতে পারে। সাইটের নিবন্ধিত একটি সার্ভিস ওয়ার্কার আপনার সামনে কোনো ট্যাব না থাকলেও একটি সারিবদ্ধ সিঙ্কের জন্য জেগে উঠতে পারে।

এর কোনোটিরই ক্লিক দরকার নেই, আর কোনোটিই নথিটি পুনরায় লোড করে না। অ্যাড্রেস বার, স্ক্রলের অবস্থান এবং রেন্ডার করা মান সবই যেখানে ছিল সেখানেই থাকে। যা বদলায় তা কেবল নেটওয়ার্কের দিক: প্রতিটি নতুন প্রচেষ্টা হলো শুরু হওয়ার মুহূর্তে নেওয়া একটি নতুন সিদ্ধান্ত।

এই পার্থক্যটি গুরুত্বপূর্ণ, কারণ দৃশ্যমান পৃষ্ঠাটি স্থানীয়ভাবে সংরক্ষিত। ইতিমধ্যে আঁকা পিক্সেল পরের অনুরোধটি সফল হয়েছে কি না তা কিছুই বলে না। স্পিনারসহ জমে যাওয়া একটি চার্ট এমন পৃষ্ঠার স্বাভাবিক চেহারা যার অনুরোধগুলো এখন ব্যর্থ হচ্ছে। স্ক্রিন পড়ে আপনি জানতে পারেন সার্ভার কয়েক মিনিট আগে কী বলেছিল, ব্রাউজার এখন কী করছে তা নয়।

কেন আগের পৃষ্ঠা লোড একটি রুট ধরে রাখে না

পৃষ্ঠা লোডে কিছুই নথিটিকে টানেলের সাথে বেঁধে দেয় না। রাউটিং প্রতিটি প্যাকেটের জন্য, পাঠানোর সময়ে, প্যাকেটটি বের হওয়ার সময় যে টেবিল থাকে তা থেকে নির্ধারিত হয়। টানেল ইন্টারফেসটি অদৃশ্য হয়ে গেলে সেই খোঁজ আর টানেল রুটের সাথে মেলে না। এটি হয় ফিজিক্যাল অ্যাডাপ্টারে গিয়ে পড়ে, নয়তো কিছুই পায় না, ক্লায়েন্ট পিছনে কী রেখেছে তার উপর নির্ভর করে।

পুনরাবৃত্ত কলব্যাকগুলো সাধারণ নির্ধারিত কাজ। HTML মানের টাইমার অংশ বর্ণনা করে সেগুলো কীভাবে সারিবদ্ধ হয় এবং ব্যবধানটিকে সুনির্দিষ্ট ছন্দের প্রতিশ্রুতি নয়, বরং ন্যূনতম বিলম্ব হিসেবে দেখে, তাই একটি ব্যাকগ্রাউন্ড ট্যাব তার কোড যতবার চায় তার চেয়ে অনেক কমবার জরিপ করতে পারে। কম প্রচেষ্টা কোনো প্রচেষ্টা না থাকার সমান নয়, এবং একটি ট্যাবকে আবার সামনে আনা সেগুলোর হঠাৎ বন্যার সাধারণ মুহূর্ত।

ব্যর্থতার নীতি কোথায় গিয়ে দাঁড়ায়

ক্লায়েন্টের ব্লক তখনই মূল্যায়িত হয় যখন সংযোগের চেষ্টা করা হয়, যখন পৃষ্ঠাটি আনা হয়েছিল তখন নয়। যদি সাধারণ অ্যাক্সেস এখনও অনুমোদিত থাকে, পুনঃপ্রচেষ্টাটি ফিজিক্যাল লিংক দিয়ে খোলাখুলিভাবে বের হতে পারে। যদি নীতি টানেল ফিরে আসা পর্যন্ত সেই ট্রাফিক ধরে রাখে, প্রচেষ্টাটি সংযোগের সময়েই ব্যর্থ হয় এবং পৃষ্ঠাটি একটি ত্রুটি দেখায় যা কয়েক সেকেন্ড পরে আবার চেষ্টা করতে পারে।

দুটি বিবরণ ঠিক করে দেয় আপনি এর মধ্যে কোনটি পাবেন। প্রথমটি হলো ক্লায়েন্ট যে প্রয়োগের পরিধি সমর্থন করে: পুরো ডিভাইসের ব্লক, টানেল অ্যাডাপ্টারে সীমিত ব্লক, বা ব্যতিক্রমসহ নিয়মের সেট। দ্বিতীয়টি হলো গন্তব্যটি আপনি আগে স্থানীয় প্রিন্টার, ক্যাপটিভ পোর্টাল বা স্ট্রিমিং পরিষেবার জন্য যোগ করা কোনো ব্যতিক্রমের ভিতরে পড়ে কি না।

অ্যাপ্লিকেশন-স্তরের এনক্রিপশন এর কিছুই বদলায় না। HTTPS ব্রাউজার ও সার্ভারের মধ্যে বাইটগুলো সুরক্ষিত রাখে; কোন ইন্টারফেস সেগুলো বহন করছে সে সম্পর্কে এটি কিছু বলে না। একটি পৃষ্ঠা নিখুঁতভাবে এনক্রিপ্টেড হয়েও ভুল পথে বের হতে পারে, এবং সংকীর্ণ ব্লক ঠিক সেটাই অনুমোদন করে।

ফেলে দেওয়া পৃষ্ঠা দিয়ে একটি নিয়ন্ত্রিত পরীক্ষা

আপনার নিয়ন্ত্রণাধীন একটি হোস্ট এবং এমন একটি পৃষ্ঠা ব্যবহার করুন যা কেবল তাকে ডাকার ছাড়া আর কিছু করে না, যাতে কোনো বাস্তব তথ্য খেলায় না থাকে। টার্মিনাল থেকে বিচ্ছেদের আগে ও পরে পথের নমুনা নিন:

curl -sS --max-time 5 -o /dev/null -w '%{http_code} %{remote_ip}\n' https://probe.example.net/ping

টানেল চালু রেখে এটি চালান, তারপর টানেল বন্ধ করুন এবং আবার চালান। টানেল বন্ধ থাকা অবস্থায় একটি পাবলিক ঠিকানা থেকে উত্তর আপনাকে বলে সরাসরি পথটি খোলা। সময় শেষ হওয়া বা সংযোগ প্রত্যাখ্যাত হওয়া আপনাকে বলে নীতি ধরে রাখছে। ক্লায়েন্ট পুনঃসংযোগ করার পরে আরও একবার পুনরাবৃত্তি করুন, যাতে টানেল পথটি ফিরে আসতে দেখেন, ধরে নেওয়ার বদলে।

ব্রাউজারে নেটওয়ার্ক প্যানেল দুটি প্রশ্নকে আলাদা করে। Fetch/XHR-এ ফিল্টার করুন, তারপর ইনিশিয়েটর কলামটি পড়ুন: টাইমার বা স্ক্রিপ্টে শুরু হওয়া একটি এন্ট্রি, যার আগে কোনো নেভিগেশন রেকর্ড হয়নি, তা পুনরায় লোড নয় বরং ব্যাকগ্রাউন্ড প্রচেষ্টা। এর শুরুর সময় টানেল যেদিন পড়েছিল সেই মুহূর্তের সাথে মেলান। টানেল চলে গেলে এন্ট্রিটি যদি এখনও পেন্ডিং থাকে, অনুরোধটি এমন একটি পথের জন্য অপেক্ষা করছে যা আর নেই।

সার্ভার-সাইড প্রমাণ ব্রাউজার যা দেখায় তার চেয়ে শক্তিশালী। টাইমস্ট্যাম্প ও উৎস ঠিকানাসহ একটি অনুরোধ লগ প্রমাণ করে প্যাকেটটি পৌঁছেছে। ব্রাউজার এন্ট্রিতে কুকি, টোকেন ও সম্পূর্ণ URL থাকতে পারে, তাই কেবল আপনার প্রশ্নের প্রয়োজনীয় ক্ষেত্রগুলো রাখুন এবং যেকোনো জায়গায় পেস্ট করার আগে বাকিগুলো লুকিয়ে দিন।

উত্তর নিয়ে কী করবেন

টানেল বন্ধ থাকা অবস্থায় ব্যাকগ্রাউন্ড প্রচেষ্টা সফল হতে থাকলে ব্লকটি আপনার ধারণার চেয়ে সংকীর্ণ, এবং সংবেদনশীল কাজের জন্য ক্লায়েন্টকে বিশ্বাস করার আগে সেই ফাঁক বন্ধ করা উচিত। যদি সেগুলো ব্যর্থ হয়, নীতি তার কাজ করছে এবং জমে যাওয়া পৃষ্ঠাটি কেবল দৃশ্যগত। যেভাবেই হোক, একটি ট্যাব বন্ধ করা ডিভাইস-ব্যাপী নিয়ন্ত্রণ নয়: অন্য ট্যাব, অন্য ব্রাউজার ও অন্য অ্যাপ্লিকেশন প্রত্যেকে নিজের কাজ নিজে নির্ধারণ করে।

যে পরবর্তী পদক্ষেপগুলো নেওয়া উচিত: আপনি কোন ব্যতিক্রমগুলো এবং কেন যোগ করেছেন তা তালিকাভুক্ত করুন, ক্লায়েন্ট কেবল টানেল-পরিধির ট্রাফিক নাকি সব ট্রাফিক ব্লক করে তা নিশ্চিত করুন, এবং সার্ভার লগ খোলা রেখে একটি ব্যাকগ্রাউন্ড অনুরোধ শুরু থেকে শেষ পর্যন্ত দেখুন। ওই তিনটি উত্তর «VPN বন্ধ হয়ে গেল আর কিছু এখনও সংযুক্ত» এমন প্রতিবেদনে আসলে যা থাকে তার বেশিরভাগটাই ঢেকে দেয়।