নতুন হটস্পট ক্লায়েন্টের IP ঠিকানা পাওয়ার সময় আটকে থাকা VPN-এর ত্রুটি নয়

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

তিনটি পর্যায়, এবং আপনি কোনটিতে আছেন

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

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

ভ্রান্ত ধারণা: রাউট করা VPN স্থানীয় DHCP-কে দূরবর্তী অনুরোধে পরিণত করে

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

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

একটি বিদ্যমান ক্লায়েন্ট কাজ করা আসলে কী প্রমাণ করে

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

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

তুলনাটি স্থানীয় ও প্রত্যাবর্তনযোগ্য রাখুন

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

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

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

লিজ কী প্রমাণ করে না

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

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