Mac-এ Cisco Secure Client: উইন্ডো, স্বয়ংক্রিয় সংযোগ নাকি পুনঃসংযোগ?

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

আপনি আসলে যে আচরণ দেখছেন তার নাম দিন

কিছু না ছুঁয়ে একটি লগইন লক্ষ্য করুন এবং কী ঘটছে তা ক্রমানুসারে লিখে রাখুন। সংযোগ ছাড়া খোলা উইন্ডো এক ক্ষেত্রে, খুলে সংযোগ করা উইন্ডো আরেক ক্ষেত্রে, আর নেটওয়ার্ক বদলানোর পর ফিরে আসা সংযোগ তৃতীয় ক্ষেত্রে। পর্দায় কী দেখা যাচ্ছে তা নয়, বরং আসলে কী টানেল তৈরি করছে তা জিজ্ঞাসা করুন, কারণ উইন্ডো ও টানেলের মালিক আলাদা। দুই ধরনের প্রমাণ এর উত্তর দেয়, আর তার মধ্যে কেবল একটি এই ক্লায়েন্টকে দেখতে পায়:

scutil --nc list
ps aux | grep -i [v]pnagentd
ifconfig | grep -A3 utun

তিনটি আউটপুট একসাথে পড়ুন, কারণ scutil --nc list সিস্টেমের VPN কনফিগারেশন তালিকাভুক্ত করে এবং খালি তালিকা কেবল বোঝায় যে কোনো সিস্টেম VPN সেবা টানেলের মালিক নয়। Cisco Secure Client এমনটি নিবন্ধন করে না: এটি vpnagentd এবং একটি utun ইন্টারফেসের মধ্য দিয়ে শেষ হয়, তাই প্রসেস ও ইন্টারফেসই সেই প্রমাণ যা এটি দেখতে পায়। যখন vpnagentd চলছে এবং একটি utun ইন্টারফেসে ঠিকানা আছে, তখন উইন্ডো বন্ধ থাকলেও টানেল থাকে; যখন দুটির কোনোটিই নেই, তখন স্বয়ংক্রিয় সংযোগ বন্ধ এবং আলোচনার জন্য কেবল উইন্ডোই থাকে। সামনের অংশটিও চলতে পারে যখন আলাদা ব্যাকগ্রাউন্ড সেবা টানেলের মালিক, তাই মালিকানার প্রশ্নটি এই অংশের নয়, প্রোফাইল অংশগুলোর।

লগইনে উইন্ডো খোলা একটি লঞ্চ প্রশ্ন

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

ম্যানেজ করা Mac-এ, আচরণটিকে স্থানীয় পছন্দ হিসেবে ধরার আগে যাচাই করুন এটি ইনস্টল করা কনফিগারেশন প্রোফাইলের মাধ্যমে আসছে কি না। সিস্টেম তার থাকা প্রোফাইলগুলো তালিকাভুক্ত করতে পারে, আর ম্যানেজ করা লগইন আইটেম আপনার মুছে ফেলার জিনিস নয়:

profiles show -type configuration

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

Auto Connect on Start আলাদা একটি পছন্দ

Cisco-র সংযোগ নির্দেশিকা Auto Connect on Start-কে সেই পছন্দ বলে যা ক্লায়েন্ট চালু হলে সংযোগের চেষ্টা নিয়ন্ত্রণ করে, এবং এটিকে ডিফল্টে বন্ধ হিসেবে বর্ণনা করে। মোতায়েন করা প্রোফাইল এটি চালু করতে পারে, তাই একই ক্লায়েন্ট থাকা দুটি Mac লগইনে ভিন্নভাবে আচরণ করে। লঞ্চ আইটেম সম্পর্কে কিছু ধরে নেওয়ার আগে ক্লায়েন্টের সেটিংসে সেই পছন্দটি খুঁজুন।

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

Auto Reconnect তৃতীয় একটি সেটিংয়ের অন্তর্গত

পুনঃসংযোগ নিয়ন্ত্রণ করে প্রতিষ্ঠিত সেশন যখন তার পথ হারায় তখন কী হয়: ঢাকনা বন্ধ হওয়া, Wi-Fi নেটওয়ার্ক বদলানো, তারযুক্ত লিংক ছিঁড়ে যাওয়া। Cisco এটি স্টার্টআপ আচরণ থেকে আলাদাভাবে নথিভুক্ত করে, তাই স্টার্টআপের বদল এটিকে স্পর্শ করবে না। নেটওয়ার্ক কিছুক্ষণ বিচ্ছিন্ন করে এবং কোনো হস্তক্ষেপ ছাড়া টানেল ফিরে আসে কি না তা দেখে এটি পরীক্ষা করুন।

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

সবচেয়ে ছোট বদল চান, তারপর তা যাচাই করুন

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

বদলের পর লগআউট করে আবার লগইন করুন, তারপর আপনার নির্ভর করা ম্যানুয়াল সংযোগ প্রবাহ চালান। পুনঃসংযোগ পরিধিতে থাকলে, আপনার প্রশাসক যে পদ্ধতি অনুমোদন করেন তা অনুসারে আলাদাভাবে পরীক্ষা করুন।

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