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

নিয়মটি কেন মেলা বন্ধ করেছিল

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

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

বিকল্প এক: একটি স্থিতিশীল ঠিকানা, কম গোপনীয়তা

সাধারণ সমাধান হোস্টে দুটি ঘূর্ণন প্রক্রিয়াই বন্ধ করে: netsh interface ipv6 set privacy state=disabled store=persistent এবং netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent। পুনরায় চালু হওয়ার অপেক্ষা না করে পরিবর্তনটি কার্যকর করতে চাইলে store=active যোগ করুন, এবং মেনে নিন যে আপনি শনাক্তকারীটিকে নেটওয়ার্কজুড়ে অনুমানযোগ্য করে তুলেছেন।

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

বিকল্প দুই: একটি প্রিফিক্স বা নাম অনুমোদন করুন

সম্পূর্ণ ঠিকানার বদলে /64 অনুমোদন করলে ঘূর্ণন অক্ষত থাকে এবং দুর্বল কিন্তু প্রায়শই সৎ দাবির সঙ্গে মিলে যায়: এই মেশিনটি আমার হোম নেটওয়ার্কে আছে। যে মুহূর্তে সেই প্রিফিক্সে এমন হোস্ট থাকে যা আপনি অনুমোদন করবেন না, এটি যথেষ্ট হওয়া বন্ধ করে, আর গ্রাহক সংযোগে এটি সাধারণত মানুষের ধারণার চেয়ে ছোট সেট। ডাইনামিক DNS-এর মাধ্যমে প্রকাশিত নাম চালানো সহজ, কারণ রেকর্ডটি হোস্টকে অনুসরণ করে এবং নীতিটি পরিচয় হিসেবে পড়া হয়, কোনো ডিভাইস যোগ হলে বাড়তে থাকা পরিসর হিসেবে নয়।

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

বিকল্প তিন: টানেলকে ঠিকানাটি বরাদ্দ করতে দিন

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

সিদ্ধান্তটি সম্পূর্ণভাবে ঠিকানা থেকে সরিয়ে নেওয়া, ক্লায়েন্ট সার্টিফিকেট বা প্রমাণীকৃত গেটওয়েতে, সেই বিকল্প যা স্কেল করে, কারণ এটি এমন মানের ওপর নির্ভর করা বন্ধ করে যা পরিবর্তন করতে অপারেটিং সিস্টেমের অধিকার আছে।

ট্র্যাকিং ব্যয়ের দিকে নজর রেখে বেছে নিন

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

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

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