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

সংখ্যাটিকে একটি ধাপ হিসেবে পড়ুন

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

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

Code familyStageWhere the evidence lives
829, 703Link or dial completionClient event log, remote listener reachability
720PPP negotiation and miniport bindingAdapter state, bindings, client log detail
691, 649, 812Identity and authorizationGateway or authentication server decision
Connected, no trafficAddressing, routing and resolutionRoute table and resolver configuration

প্রথম ধাপ: লিংক ও ডায়াল প্রচেষ্টা

829 মানে অন্তর্নিহিত লিংকটি বিচ্ছিন্ন হয়েছে। এটি বলে না দূরবর্তী পিয়ার উত্তর দেওয়া বন্ধ করেছে, একটি মিডলবক্স সেশনটি মেরে ফেলেছে, নাকি ক্লায়েন্টের একটি নীতি এটি বন্ধ করেছে। 703-এর মতো ডায়াল-সমাপ্তি কোড আরও আগের: প্রচেষ্টাটি লিংক হওয়ার মতো দূরেও যায়নি, যা সাধারণত প্রোফাইল, সেবার অবস্থা বা স্থানীয় নীতির দিকে ইঙ্গিত করে।

Get-VpnConnection -Name 'Corp' | Select-Object Name,ServerAddress,TunnelType,AuthenticationMethod,ConnectionStatus
Test-NetConnection -ComputerName vpn.example.net -Port 443
Get-WinEvent -LogName Application -MaxEvents 200 | Where-Object ProviderName -match 'RasClient' | Select-Object -First 15 TimeCreated,Id,Message

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

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

দ্বিতীয় ধাপ: PPP ও মিনিপোর্ট বাইন্ডিং

720 লিংক ও ব্যবহারকারীর মাঝখানে অবস্থান করে। টানেল উঠে এসেছিল আর তারপর PPP স্তর একটি ঠিকানা বা নিয়ন্ত্রণ প্রোটোকল নিয়ে দর কষাকষি করতে পারেনি, যা প্রায়ই ক্লায়েন্টে একটি বাইন্ডিং সমস্যা, প্রত্যাখ্যাত শংসাপত্র নয়। এই পার্থক্যই কোডের সম্পূর্ণ মূল্য: এটি বলে শংসাপত্রে পৌঁছানোই হয়নি, তাই অ্যাকাউন্ট সন্দেহভাজন নয়।

Get-NetAdapter -IncludeHidden | Where-Object InterfaceDescription -match 'WAN Miniport' | Select-Object Name,Status,ifIndex
Get-NetAdapterBinding | Where-Object ComponentID -match 'ms_pptp|ms_l2tp|ms_sstp|ms_agile' | Select-Object Name,ComponentID,Enabled

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

তৃতীয় ধাপ: পরিচয় ও অনুমোদন

691 মানে শংসাপত্র প্রত্যাখ্যাত হয়েছে। 649 মানে অ্যাকাউন্টটিকে ডায়াল করার অনুমতি নেই, আর 812 মানে একটি দূরবর্তী অ্যাক্সেস নীতি সংযোগটি প্রত্যাখ্যান করেছে। এগুলো সিদ্ধান্ত, পরিবহন ত্রুটি নয়, আর ক্লায়েন্ট কেবল এগুলো রিপোর্ট করতে পারে।

প্রমাণ অন্য পাশে। গেটওয়ে অপারেটরকে ওই টাইমস্ট্যাম্পের প্রচেষ্টা ও যে নীতি মিলেছিল তা জিজ্ঞাসা করুন; ডিরেক্টরি মালিককে জিজ্ঞাসা করুন অ্যাকাউন্টের ডায়াল-ইন অনুমতি আছে কি না এবং এটি নীতির প্রয়োজনীয় দলে আছে কি না। টানেলের ধরন বদলানো বা ক্লায়েন্ট পুনরায় ইনস্টল করা একটি পরিচয় সম্পর্কে নেওয়া সিদ্ধান্ত বদলাতে পারে না।

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

চতুর্থ ধাপ: সংযুক্ত, এবং কিছুই কাজ করে না

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

Get-NetRoute -DestinationPrefix 10.24.0.0/16 | Select-Object DestinationPrefix,NextHop,InterfaceAlias
Resolve-DnsName files.corp.example.internal
Test-NetConnection -ComputerName 10.24.6.15 -Port 445

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

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

এক প্রচেষ্টা, এক পরিবর্তন, এক রেকর্ড

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

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

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

সম্পর্কিত নিবন্ধ