VPN আবার সংযুক্ত হলো, তবুও অ্যাপের সেশন ব্যর্থ হয়

টানেল ফিরে আসে, ক্লায়েন্ট বলে সংযুক্ত, অথচ ব্রাউজার এখনো সেই পাতায় ঘুরছে যা সে বিচ্ছিন্ন হওয়ার আগে লোড করছিল। VPN-এর পুনঃসংযোগ একটি পথ ফিরিয়ে দেয়, আর অ্যাপ্লিকেশন ও দূরপ্রান্ত পুরনো পথে যে সংযোগ-অবস্থা জমিয়েছিল তা ফিরিয়ে দেয় না। এরা মেরামতের জন্য আলাদা দুটি জিনিস, আর এদের গুলিয়ে ফেললে আপনি বিনা কারণে VPN সেটিংসে ফিরে যান।

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

পুনঃসংযোগে কী টিকে থাকে আর কী থাকে না

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

কিছু ক্লায়েন্ট পুনঃসংযোগের সময় পুরনো সংযোগ ফেলে দেওয়ার একটি হুক যোগ করে, আর অধিকাংশই করে না। এখানে আচরণ ক্লায়েন্ট, প্ল্যাটফর্ম ও সংস্করণভেদে বদলায়।

দূরপ্রান্ত আপনাকেও ভুলে গেছে

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

সার্ভারের দিকে নিষ্ক্রিয়তার সময়সীমা নিজের সময়সূচিতে একই কাজ করে, তাই কোনো নেটওয়ার্ক ঘটনা ছাড়াই একটি সেশন মরে যেতে পারে। সার্ভার যতটা আশা করে তার চেয়ে বেশি সময় নিষ্ক্রিয় থাকা সংযোগ আপনি টানেলের স্থানান্তর টের পাওয়ার আগেই চলে যায়।

নতুন অনুরোধই সেই পরীক্ষা যা এদের আলাদা করে

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

পরীক্ষার সময় সরাসরি ট্রাফিকের যেকোনো ব্লক চালু রাখুন। আকস্মিক বিকল্প পথ দিয়ে সফল হওয়া অনুরোধ টানেল সম্পর্কে কিছুই প্রমাণ করে না।

পুরনো নয়, নতুন সংযোগ দিয়ে নিশ্চিত করুন

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

ss -tanp | grep -E ':(443|8443)'
curl -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 https://intranet.example.com/
conntrack -L 2>/dev/null | grep 8443
dig +short intranet.example.com

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

বাধার সময়, পুনঃসংযোগের সময় এবং পুরনো ও নতুন অনুরোধের মধ্যে পার্থক্য লিখে রাখুন। সেই রেকর্ডই অস্পষ্ট অভিযোগকে এমন প্রতিবেদনে বদলে দেয় যা নিয়ে কেউ কাজ করতে পারে।