সুড়ঙ্গটি বন্ধ হওয়ার পর IPv4 দিয়ে কোনো সাইটে পৌঁছে গেলেও IPv6 সম্পর্কে আপনি কিছুই প্রমাণ করেননি। macOS দুই পরিবারকে প্রতিটি নেটওয়ার্ক সেবার জন্য আলাদাভাবে কনফিগার করে, আর একটি VPN ক্লায়েন্ট একটি পরিবর্তন করে অন্যটি স্পর্শ না করেই। তিনটি স্তর ক্রমানুসারে কাজ করুন: ঠিকানা কনফিগারেশন, রুট নির্বাচন, তারপর বিচ্ছিন্ন অবস্থায় ক্লায়েন্ট যে নীতি ইনস্টল করে। এই সময়ে অ্যাক্সেস নেটওয়ার্ক অপরিবর্তিত রাখুন, নইলে আপনি দুটি ভিন্ন সমস্যার তুলনা করবেন।

যে পরিবারটি সত্যিই ভেঙেছে সেখান থেকেই শুরু করুন

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

পুরো তুলনার সময় একই Wi-Fi নেটওয়ার্ক ও অ্যাক্সেস পয়েন্ট রাখুন। গতকাল IPv6 দিয়েছিল এমন একটি ক্যাফে নেটওয়ার্ক এখন আপনি যে নেটওয়ার্কে আছেন সে সম্পর্কে কিছুই বলে না।

রুটের আগে ঠিকানাটি পড়ুন

সিস্টেম সেটিংসে সক্রিয় সেবার TCP/IP প্যানেল দেখায় IPv6 স্বয়ংক্রিয়, ম্যানুয়াল বা শুধু লিংক-লোকাল কি না। প্রত্যাশার সঙ্গে তা মেলান, মনে রাখুন কোনো প্রতিষ্ঠান ইচ্ছাকৃতভাবে ম্যানুয়াল কনফিগারেশন বেছে নিতে পারে। তারপর চালান ifconfig এবং সংশ্লিষ্ট ইন্টারফেসটি পড়ুন। কেবল একটি fe80:: ঠিকানা মানে ইন্টারফেসটি তার প্রতিবেশীদের সঙ্গে কথা বলতে পারে এবং আর কিছুই নয়, তাই লিংক-লোকাল উপস্থিতি ব্যবহারযোগ্য পথের প্রমাণ নয়।

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

ব্যর্থ গন্তব্যের জন্য রুট টেবিলটি পড়ুন

কার্নেলকে ব্যর্থ গন্তব্যটি সম্পর্কে জিজ্ঞাসা করুন, ডিফল্ট রুট সম্পর্কে নয়। route -n get 2001:db8::25 ওই ঠিকানার জন্য নির্বাচিত ইন্টারফেস ও গেটওয়ে ছাপে, আর netstat -rn -f inet6 তুলনার জন্য পুরো টেবিলটি দেখায়। ডিফল্ট রুট আপনাকে বলে একটি ডিফল্ট আছে; এটি বলে না এই গন্তব্যটি সেটি ব্যবহার করে।

DNS-কে তার নিজের কক্ষে রাখুন। IPv4 দিয়ে পৌঁছানো যায় এমন একটি রিজলভার এখনও AAAA রেকর্ড ফেরত দিতে পারে, তাই লুকআপ ব্যর্থতা ও রাউটিং ব্যর্থতা ব্রাউজারে একই উপসর্গ তৈরি করে।

ক্লায়েন্টের ব্লক নীতিকে অবশিষ্টাংশ থেকে আলাদা করুন

কিছু ক্লায়েন্ট বিচ্ছিন্ন থাকা অবস্থায় ট্রাফিক ব্লক করার জন্য তৈরি, অন্য ঠিকানা পরিবারটিসহ, এবং এই আচরণ একটি বৈশিষ্ট্য, ত্রুটি নয়।

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

প্রমাণ সংগ্রহ করুন, তারপর একটি জিনিস বদলান

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

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

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