Windows-এ নেটওয়ার্ক রিসেট VPN ত্রুটির চেয়ে বেশি মুছে ফেলে
রিসেট কেবল বিকল টানেল নয়, অ্যাডাপ্টার, রুট ও WFP ফিল্টার পরিষ্কার করে। আগে প্রোফাইল, সার্টিফিকেট তালিকা ও প্রমাণ সংরক্ষণ করুন, তারপর স্তরে স্তরে পরীক্ষা করুন।
প্রতিটি Windows VPN অভিযোগের দশ মিনিটের মধ্যে পরামর্শ আসে: নেটওয়ার্ক রিসেট চালাও, এটি সব ঠিক করে দেয়। করে না, এবং এটি সংকীর্ণ নয়। ওই বোতাম অ্যাডাপ্টার পরিষ্কার করে, প্রোটোকল আবার বাঁধে, স্ট্যাটিক ঠিকানা ও ডিফল্ট রুট সরায়, ফায়ারওয়াল ও ফিল্টার এন্ট্রি ফেলে দেয়, এবং উপরন্তু Wi-Fi প্রোফাইলও ভুলে যায়। চলমান কিন্তু ভুলভাবে কনফিগার করা টানেলযুক্ত মেশিনে এটি একটি নির্ণয়যোগ্য ত্রুটিকে নথিহীন পুনর্নির্মাণে পরিণত করে। আগে পাঁচটি জিনিস সংরক্ষণ করুন, তাহলে এটি ফিরিয়ে আনার বিকল্প থাকবে।
রিসেট VPN প্রোফাইলে সীমাবদ্ধ নয়
VPN সংযোগ হলো নেটওয়ার্ক স্ট্যাক ভাগ করে নেওয়া অনেকগুলোর একটি বস্তু। অ্যাডাপ্টার সরিয়ে আবার যোগ করা ইন্টারফেস সূচক বদলায়, এবং যে কিছু সেই সূচক উল্লেখ করত, রুট থেকে ফায়ারওয়াল নিয়ম ও তৃতীয় পক্ষের ফিল্টার ড্রাইভার পর্যন্ত, এখন এমন কিছু উল্লেখ করে যা আর নেই।
ভার্চুয়ালাইজেশন এটিকে আরও খারাপ করে। Hyper-V সুইচ, VMware ব্রিজ, কনটেইনার নেটওয়ার্ক এবং নিজস্ব ভার্চুয়াল অ্যাডাপ্টারযুক্ত VPN ক্লায়েন্ট সবাই একই জায়গায় থাকে। যে রিসেট ভিত্তি স্ট্যাক পুনঃস্থাপন করে তা ওই উপাদানগুলো অর্ধেক রেখে যেতে পারে, এবং ফলস্বরূপ মেশিন চলমান হার্ডওয়্যার রিপোর্ট করে কোনো চলমান পথ ছাড়াই।
এর কোনোটিই কখনো রিসেট না করার পক্ষে যুক্তি নয়। এটি প্রথমে রিসেট না করার পক্ষে যুক্তি, এমন মেশিনে যার নথি আপনি রাখেননি, যখন প্রকৃত ত্রুটি একটি রুট এন্ট্রি বা একটি পুরোনো ফিল্টার হতে পারে। রিসেট একটি প্রশস্ত হাতিয়ার যার সাফল্যের হার সংকীর্ণ, এবং এটিকে প্রথম পদক্ষেপ করা নিশ্চিত করে যে দুটির মধ্যে কোনটি ছিল তা আপনি কখনো জানবেন না।
সেটিং সংরক্ষণের আগে প্রমাণ সংরক্ষণ করুন
ত্রুটিটি নিজেই উপাত্ত। সঠিক ত্রুটি কোড, সময়, কোন প্রোফাইল নির্বাচিত ছিল, এবং গেটওয়ে আদৌ কোনো প্রচেষ্টা লগ করেছে কি না লিখুন। যে কোড বলে টানেল কখনো উত্তর পায়নি এবং যে কোড বলে প্রমাণীকরণ ব্যর্থ হয়েছে তারা সম্পূর্ণ ভিন্ন মেরামতের দিকে ইঙ্গিত করে। রিসেটের পরে হয়তো দুটির কোনোটিই পুনরুৎপাদন করতে পারবেন না। ভাঙা অবস্থাকে এমন সম্পদ হিসেবে দেখুন যা আপনি এইমাত্র খরচ করতে যাচ্ছেন।
অবস্থাটি এখনো ভাঙা থাকতেই ধারণ করুন, মেশিনের অস্থায়ী ফোল্ডারের বাইরে একটি ফোল্ডারে:
mkdir C:\vpn-evidence
ipconfig /all > C:\vpn-evidence\ipconfig.txt
route print > C:\vpn-evidence\routes.txt
Get-VpnConnection -AllUserConnection | Export-Csv C:\vpn-evidence\profiles.csv -NoTypeInformation
netsh wfp show state file=C:\vpn-evidence\wfp.xmlশেষ কমান্ডটিই মানুষ বাদ দেয়, এবং প্রায়ই সেটিই ত্রুটি ব্যাখ্যা করে। সরানো ক্লায়েন্টের অবশিষ্ট ফিল্টার স্থায়ী নীতি হিসেবে বেঁচে থাকে, এবং রপ্তানি করা XML তাদের একমাত্র স্থানীয় রেকর্ড। রিসেট আপনার শনাক্ত করার চেষ্টা করা জিনিসটি মুছে ফেলার আগে এটি পড়ুন।
যে কনফিগারেশন ফিরে আসবে না তা সংরক্ষণ করুন
কিছু সেটিং স্বয়ংক্রিয়ভাবে আবার তৈরি হয়। স্ট্যাটিক ঠিকানা, কাস্টম রুট, DNS প্রত্যয়, প্রক্সি ব্যতিক্রম ও ফায়ারওয়াল নিয়ম তৈরি হয় না। প্রোফাইলগুলোও নয়, যারা একটি ফোনবুক ফাইলে থাকে যা রিসেট আপনার জন্য পুনরুদ্ধার করে না।
| What to save | Where it lives | Why the reset loses it |
|---|---|---|
| VPN profiles | rasphone.pbk in ProgramData or the user profile | Profiles are not part of the adapter state |
| Static IP and DNS | Adapter configuration | Adapters are removed and recreated |
| Persistent filters | WFP policy store | Filter state is cleared with the stack |
| Third-party bindings | Adapter binding list | Components must be reinstalled manually |
Get-NetIPConfiguration | Out-File C:\vpn-evidence\netip.txt
Get-NetRoute -AddressFamily IPv4 | Export-Csv C:\vpn-evidence\netroutes.csv -NoTypeInformation
Get-DnsClientServerAddress | Export-Csv C:\vpn-evidence\dns.csv -NoTypeInformation
Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject,Thumbprint,NotAfterসার্টিফিকেট তালিকা দেখতে যতটা মনে হয় তার চেয়ে গুরুত্বপূর্ণ। নেটওয়ার্ক রিসেট ক্লায়েন্ট সার্টিফিকেট ধ্বংস করে না, কিন্তু তালিকা বলে প্রোফাইল কোনগুলোর উপর নির্ভর করত এবং কোনটি শিগগিরই মেয়াদোত্তীর্ণ হচ্ছে। পুনর্নির্মাণের পরে মেয়াদোত্তীর্ণ সার্টিফিকেট আবিষ্কার পুনর্নির্মাণ নষ্ট করে।
শুরুর আগে পুনরুদ্ধারের পথ লিখুন
যদি মেশিন দূরে থাকে এবং VPN-ই আপনার একমাত্র প্রবেশপথ হয়, রিসেট আপনার সেশন শেষ করতে পারে এবং সাইটে কেউ না থাকলে ফেরার পথ নাও থাকতে পারে। অ্যাডাপ্টার স্পর্শ করে এমন কিছু চালানোর আগে নিশ্চিত করুন যে ব্যান্ডের বাইরে প্রবেশ আছে, বা একজন ব্যক্তি উপলব্ধ।
ইনস্টলার ও সংযোগের বিবরণ এমন জায়গায় রাখুন যেখানে মেশিন পরে এখনো পৌঁছাতে পারে। যে ক্লায়েন্টকে টানেল দিয়ে পৌঁছানো বিক্রেতা পোর্টাল থেকে পুনঃস্থাপন করতে হয় তা চক্রাকার নির্ভরতা, এবং এটিই এই প্রক্রিয়া সেবা বন্ধে পরিণত হওয়ার সবচেয়ে সাধারণ উপায়।
তারপর লিখুন আপনি কী করছেন এবং কেন, সঠিক কমান্ডসহ। পরের ব্যক্তিকে জানতে হবে রিসেট পরীক্ষা ছিল না সিদ্ধান্ত, এবং “আমরা সব চেষ্টা করেছি” কোনো রেকর্ড নয়।
রিসেটের পরে স্তরে স্তরে পরীক্ষা করুন
একসাথে অনেক কিছু পুনরুদ্ধার করলে ফলাফল অপাঠ্য হয়ে যায়। নিচ থেকে কাজ করুন: অ্যাডাপ্টার ও ঠিকানা, তারপর নাম সমাধান, তারপর টানেলের পরিচয় পর্যায়, তারপর অ্যাপ্লিকেশন। প্রতিটি স্তরের নিজের প্রশ্নের উত্তর দেওয়া একটি কমান্ড আছে:
Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object Name,InterfaceDescription
Resolve-DnsName intranet.example.internal
Get-VpnConnection -Name 'Corp' | Select-Object ConnectionStatus,TunnelType
Test-NetConnection -ComputerName intranet.example.internal -Port 443যদি অ্যাডাপ্টার স্তর সুস্থ থাকে আর সমাধান না থাকে, থামুন এবং সমাধান ঠিক করুন। সেই মুহূর্তে VPN ক্লায়েন্ট পুনঃস্থাপন একটি চলক যোগ করে এবং একটি সূত্র সরিয়ে দেয়। কেবল যে সেটিংগুলো আপনি ব্যাখ্যা করতে পারেন সেগুলো, এক এক করে পুনরুদ্ধার করুন, এবং প্রতিটির পরে একই স্তর যাচাই করুন।
মাইক্রোসফটের নিজস্ব ত্রুটি 720-এর সমস্যা সমাধান নির্দেশিকা, উদাহরণস্বরূপ, সাধারণ রিসেট নির্দেশ করার বদলে বাইন্ডিং সমস্যাকে ঠিকানা বণ্টন সমস্যা থেকে আলাদা করে, এবং এটিই এই পরিবারের প্রতিটি কোডের জন্য সঠিক সহজাত প্রবৃত্তি। সবচেয়ে প্রশস্ত উপলব্ধ হাতিয়ারের দিকে যাওয়ার আগে কোড কী দাবি করে তা পড়ুন।