Windows-এ VPN ত্রুটি 720: ঠিকানা পুল নাকি ক্লায়েন্ট বাইন্ডিং?
ত্রুটি 720 মানে সংযোগটি কখনও ব্যবহারযোগ্য ঠিকানা পায়নি। অ্যাডাপ্টার পুনরায় ইনস্টল করার আগে একটি হোস্টের ব্যর্থতাগুলোকে অনেক হোস্টের ব্যর্থতা থেকে আলাদা করুন।
ত্রুটি 720 ক্রেডেনশিয়াল গ্রহণ করার পরে দেখায়, তাই এটি মানুষকে পাসওয়ার্ড ক্ষেত্রে ফিরিয়ে পাঠায়। সংযোগ সেই বিন্দুতে পৌঁছেছিল যেখানে ঠিকানা নিয়ে দরকষাকষি হয় এবং কোনো ঠিকানা পায়নি। দুটি সম্পূর্ণ ভিন্ন ব্যর্থতা একই ডায়ালগ তৈরি করে: সার্ভারের বিতরণ করার কিছু ছিল না, বা এই ক্লায়েন্টই দরকষাকষি সম্পূর্ণ করতে পারেনি। কিছু স্পর্শ করার আগে এই দুটিকে আলাদা করাই মেরামতের বড় অংশ, এবং এই পার্থক্য Microsoft-এর ত্রুটি 720 সমস্যা সমাধানের পাতায় নথিভুক্ত।
ডায়ালগ যা বলে না
বার্তাটি PPP দরকষাকষিতে ব্যর্থতা বর্ণনা করে, এবং এটি ইচ্ছাকৃতভাবে অস্পষ্ট কারণ ক্লায়েন্ট দেখতে পায় না কেন সার্ভার অস্বীকার করেছে। এটি ক্রেডেনশিয়ালের ত্রুটি নয় এবং টানেলের এনক্রিপশন সম্পর্কে কোনো বিবৃতি নয়। এর অর্থ হলো ঠিকানা বা দরকষাকষির প্যারামিটার পৌঁছায়নি।
সার্ভারের দিকে সাধারণ কারণ হলো বরাদ্দ: খালি ঠিকানা ছাড়া স্থির RRAS পুল, বা এমন DHCP কনফিগারেশন যার পরিসর শেষ বা দুর্গম, প্রতিটি চেষ্টাকারী ক্লায়েন্টে ঠিক এই লক্ষণ তৈরি করে। ক্লায়েন্টের দিকে সাধারণ কারণ হলো বাইন্ডিং। PPP বহনকারী WAN Miniport-কে সঠিক উপাদানের সাথে বাঁধতে হয়, এবং নিষ্ক্রিয় বাইন্ডিং বা ঢোকানো নেটওয়ার্ক ফিল্টার কোনো দৃশ্যমান ডিভাইস সমস্যা ছাড়াই দরকষাকষি থামাতে পারে। দুটি পরিবারের আলাদা প্রমাণ দরকার, এবং তাদের মধ্যে বেছে নেওয়ার দ্রুততম উপায় হলো কতজন ক্লায়েন্ট ক্ষতিগ্রস্ত তা গণনা করা।
আগে জনসংখ্যা আলাদা করুন, তারপর পুল
কোনো কনফিগারেশন পড়ার আগে ক্ষতিগ্রস্ত ক্লায়েন্ট গণনা করুন। যে ব্যর্থতা সবাইকে একসাথে আঘাত করে তা সার্ভারের অবস্থা, আর যে ব্যর্থতা একটি মেশিনকে নেটওয়ার্কের মধ্যে অনুসরণ করে তা ক্লায়েন্টের অবস্থা। এই গণনা চ্যাট চ্যানেলে একটি বার্তার খরচে হয় এবং একটি দুপুর বাঁচায়।
| Artifact | How you get it | What it rules out | What it cannot rule out |
|---|---|---|---|
| Affected-client count | One message to the people who failed, or a search of today's tickets | A client-only fault, when every client failed within minutes | Which server-side component stopped allocating |
| RRAS event for one attempt | Get-WinEvent on the System log, filtered to the allocation event id | An allocation failure, when no event matches that attempt | A binding fault that appears later in the same negotiation |
| Hidden WAN Miniport bindings | Get-NetAdapter with hidden adapters, then the binding list on the returned name | A disabled ms_wanarp binding or an inserted filter on this client | Pool exhaustion that would also have hit other clients |
| Free-address count | The RRAS pool view, or the DHCP scope statistics | A committed static range or an exhausted scope | Why the address was not delivered to one specific client |
তারপর একটি ব্যর্থ প্রচেষ্টাকে সার্ভারের নিজস্ব রেকর্ডের সাথে সম্পর্কিত করুন, কারণ RRAS বরাদ্দ করতে না পারলে একটি ঘটনা লগ করে এবং সেই ঘটনা লক্ষণের বদলে ব্যর্থতার নাম বলে। ব্যর্থতা যদি নির্দিষ্ট কোনো ক্লায়েন্টকে অনুসরণ করে, সার্ভার লগ সেই প্রচেষ্টার জন্য কিছু দেখাবে না, যা নিজেই তথ্যপূর্ণ। বরাদ্দ ত্রুটি না থাকা সমস্যাটিকে সেই ক্লায়েন্টের দরকষাকষিতে সীমিত করে এবং পরে কোন কমান্ড চালাতে হবে তা বলে।
Get-WinEvent -LogName System -MaxEvents 500 | Where-Object { $_.Id -eq 20167 }
Get-NetAdapter -IncludeHidden | Where-Object { $_.InterfaceDescription -like "WAN Miniport*" }সার্ভারের বরাদ্দ অবস্থা পড়ুন
RRAS-এর দিকে নিশ্চিত করুন কোন বরাদ্দ পদ্ধতি সত্যিই কনফিগার করা আছে, নয় যা ডকুমেন্টেশন ধরে নেয়। স্থির পুল এবং DHCP-এর মাধ্যমে পাঠানো কনফিগারেশন ভিন্নভাবে ব্যর্থ হয়, এবং সংশোধন ব্যবহৃতটিরই। স্থির পুলে খালি ঠিকানা গণনা করুন এবং প্রতি ব্যবহারকারীর বরাদ্দ খুঁজুন যারা এমন লিজ রাখে যা কেউ মনে করে না কখন দেওয়া হয়েছিল, কারণ বড় দেখানো পুল সম্পূর্ণ ভরতি থাকতে পারে। DHCP-তে যাচাই করুন রিলে কোনো সার্ভারে পৌঁছায় এবং পরিসরে খালি লিজ আছে।
সাধারণ ক্লায়েন্টের দ্বারা নিঃশেষিত পরিসর ভুল কনফিগার করা পুলের মতোই একই 720 তৈরি করে, এবং RRAS কনসোল উভয় ক্ষেত্রেই সম্পূর্ণ সুস্থ দেখাবে। পুলকে ছোট পরিসরে ভাগ করার উত্তরাধিকারী সমাধানের বিরোধিতা করুন: মূল পরামর্শ একজন প্রশাসকের ফলাফল বর্ণনা করেছিল, এবং এটি এমন বরাদ্দ ব্যর্থতা সারায় না যার নাম সার্ভারের নিজস্ব ঘটনাগুলো সরাসরি বলতে পারে।
ক্লায়েন্টের বাইন্ডিং না ভেঙে পড়ুন
প্রমাণ যদি একটি ক্লায়েন্টের দিকে ইঙ্গিত করে, স্ট্যাক পুনরায় ইনস্টল করার বদলে লুকানো অ্যাডাপ্টার পরীক্ষা করুন। প্রথম কমান্ড WAN Miniport ইন্টারফেস এবং তাদের নাম তালিকাভুক্ত করে; দ্বিতীয়টি যে নাম ফিরিয়েছে তা নেয়, কোনো গাইড থেকে অনুলিপি করা নাম নয়।
Get-NetAdapterBinding -Name "<name>" -IncludeHidden -AllBindingsতালিকাটি ঠিকানা-সমাধান বাইন্ডিং এবং তৃতীয় পক্ষের ফিল্টারের জন্য পড়ুন। নিষ্ক্রিয় বাইন্ডিং একটি লক্ষ্যযুক্ত মেরামত, অন্যদিকে ফিল্টারের উপস্থিতি সেই সফটওয়্যারের মালিকের কাছে প্রশ্ন, নিরাপত্তা পণ্য নিষ্ক্রিয় করার অনুমতি নয়। সমস্ত অ্যাডাপ্টার মুছে ফেলা একমাত্র পদক্ষেপ যা ব্যর্থতা ফিরে এলে প্রয়োজনীয় প্রমাণ ধ্বংস করে।
সংশোধনের পরে একই প্রোফাইল আবার চেষ্টা করুন এবং তারপর দুই-ক্লায়েন্ট কেসটি পুনরাবৃত্তি করুন যদি সেটিই মূল লক্ষণ ছিল, কারণ সফল প্রথম সংযোগ দ্বিতীয় ক্লায়েন্ট যে বরাদ্দ সমস্যা প্রকাশ করে তা লুকিয়ে রাখে। নোটটি চারটি ক্ষেত্রে রাখুন: কোন ক্লায়েন্ট, কোন বাইন্ডিং, কোন ঘটনা এবং কী বদলেছে। প্রতিটি প্রচেষ্টায় একটি স্তর পরিবর্তন করুন, কারণ ক্লায়েন্ট সংশোধন এবং পুল পরিবর্তন একসাথে প্রয়োগ করলে সেগুলো আরোপ করা যায় না, এবং পরবর্তী ব্যর্থতা একই হলেও নতুন দেখাবে।