GVC Acquiring IP-তে আটকে আছে: এটি পাসওয়ার্ডের সমস্যা নয়

Global VPN Client Acquiring IP-তে থেমে থাকে, আর প্রথম প্রতিক্রিয়া হয় পাসওয়ার্ড আবার লেখা বা ক্লায়েন্ট পুনরায় ইনস্টল করা। কোনোটিই যে ধাপে ব্যর্থতা ঘটেছে সেটিকে স্পর্শ করে না। ক্লায়েন্ট ঠিকানা চাওয়ার আগেই প্রমাণীকরণ সম্পন্ন হয়েছে, তাই ওই লাইনে আপনাকে আটকে রাখা জিনিসটি শংসাপত্র নয়। আপনাকে সেখানে আটকে রাখে একটি DHCP বিনিময় যা শেষ হয়নি, এবং সেটি তিনটি ভিন্ন জায়গায় আটকে যেতে পারে।

প্রমাণীকরণ ও ঠিকানা নির্ধারণ আলাদা ধাপ

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

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

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

লিজটি আসলে কোথা থেকে আসে

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

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

কিছু পরীক্ষা করার আগে লিখে রাখুন আপনার স্থাপনা কোন মডেল ব্যবহার করে। ইন্টারনেটে পরস্পরবিরোধী পরামর্শের অর্ধেকটি অন্য মডেল ধরে নেয়।

টানেল চালু থাকলেও লিজ হারাতে পারে

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

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

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

লিজের পথ ধাপে ধাপে অনুসরণ করুন

অ্যাডাপ্টার থেকে শুরু করে বাইরের দিকে যান, যাতে প্রতিটি ধাপ কেবল একটি কারণে ব্যর্থ হতে পারে:

> Get-NetAdapter | Where-Object Name -like "*GVC*"
> ipconfig /all | findstr /i /c:"GVC" /c:"IPv4" /c:"DHCP"
> Test-NetConnection 10.60.0.1 -Port 443

169.254.x.x-এর মতো ঠিকানা মানে অ্যাডাপ্টার আছে এবং কোনো উত্তরই পায়নি, যা লিজের উৎস বা ডেটা পথের দিকে ইঙ্গিত করে। VPN পরিসরে সঠিক ঠিকানা কিন্তু ভুল DNS এন্ট্রি ভিন্ন ত্রুটি: লিজ কাজ করেছে আর নীতিমালা অসম্পূর্ণ সেটিংস দিয়েছে। যে অ্যাডাপ্টার কখনও দেখা যায় না তার মানে ক্লায়েন্ট এটি তৈরি করার পর্যন্ত পৌঁছায়নি।

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

ভার্চুয়াল অ্যাডাপ্টার নিয়ে SonicWall-এর নোট এতে কয়েকটি আলাদা শাখা তালিকাভুক্ত আছে, আর এর পুরোনো স্ক্রিনশটগুলিকে বর্তমান মেনু-মানচিত্র হিসেবে পড়া উচিত নয়। আপনি কোন ধাপে পৌঁছেছেন তা নিশ্চিত করতে এটি ব্যবহার করুন, সম্পূর্ণভাবে প্রয়োগ করার চেকলিস্ট হিসেবে নয়।