সেই সংরক্ষিত Mac VPN প্রোফাইলের পিছনে কোন প্রোটোকল?
Mac-এ সংযোগের নাম তার VPN ধরন সম্পর্কে কিছুই বলে না। পেলোডের VPNType ফিল্ড পড়ুন, তারপর গেটওয়ে ও সেশন আলাদাভাবে যাচাই করুন।
কেউ একটি Mac সংযোগের নাম দেয় „অফিস VPN“, লেবেলটি দুটি সার্ভার মাইগ্রেশন পার হয়, আর প্রোটোকল বদলানোর অনেক পরে সবাই এটিকে অফিস VPN বলেই ডাকে। নামটি কনফিগারেশনের পাশে রাখা একটি ডাকনাম; Mac কী নিয়ে দরকষাকষি করে তার প্রমাণ নয়। ঘোষিত ধরনটি পড়তে লাগে একটি ফিল্ড, আর সেই সংরক্ষিত ধরনকে জীবন্ত সেশন থেকে আলাদা করতে লাগে আরও একটি ধাপ। এখানে সেই ক্রম, যা অনুমান এড়ায়।
লেবেলটি ডাকনাম, পেলোডই ধরন ঘোষণা করে
macOS VPN সেবা হলো একটি সিস্টেম কনফিগারেশন এন্ট্রি, যার একটি প্রদর্শিত নাম, একটি মালিক ক্লায়েন্ট ও একগুচ্ছ টাইপকৃত সেটিংস আছে। প্রদর্শিত নাম মুক্ত টেক্সট, এন্ট্রিটি যে তৈরি করেছে সে-ই সম্পাদনা করতে পারে, আর ব্যবহারকারীরা মেনু বারে যা দেখেন তা-ই এই অংশ। সেটিংসে থাকে আসল তথ্য: কোন সংযোগ ধরন, কোন গেটওয়ে, কোন প্রমাণীকরণ ব্যবস্থা। দুটিকে মিলিয়ে রাখে এমন কিছু নেই, তাই „L2TP অফিস“ নামের একটি প্রোফাইল IKEv2 সেবা হতে পারে।
ব্যক্তিগতভাবে তৈরি সংযোগের ক্ষেত্রে মালিক অ্যাপ্লিকেশন বা সিস্টেমের নিজস্ব VPN প্যানেল ওই সেটিংস দেখায়। ম্যানেজ করা Mac-এ প্রোফাইলটি প্রশাসকের, আর সঠিক পদক্ষেপ হলো ম্যানেজ করা পেলোড সম্পাদনা না করে একটি অসংবেদনশীল সারাংশ চাওয়া। দুটি ক্ষেত্রেই মেনু বারে একই রকম দেখায়, অথচ ভেতরে সম্পূর্ণ ভিন্ন আচরণ করে। একটি আপনার পরীক্ষা ও পরিবর্তনের জন্য; অন্যটি স্থাপিত এবং পরের চেক-ইনে পুনরুদ্ধার হবে।
এই পার্থক্যটি গুরুত্বপূর্ণ, কারণ ম্যানেজ করা ও ব্যক্তিগত কনফিগারেশন ভিন্নভাবে পরিচালিত হয়। ম্যানেজমেন্টের ইনস্টল করা প্রোফাইল প্রতিস্থাপিত বা পুনরায় প্রয়োগ হবে, তাই স্থানীয় সম্পাদনা হয় ব্যর্থ হয়, নয়তো নীরবে ফিরে যায়। আপনার নিয়ন্ত্রণে নেই এমন ফাইলের রিভার্স ইঞ্জিনিয়ারিং না করে মালিকের কাছে ধরন, গেটওয়ে পরিচয় ও প্রমাণীকরণ পদ্ধতি চান।
পেলোডের অন্য কিছুর আগে VPNType পড়ুন
Apple-এর ম্যানেজ করা VPN পেলোড স্কিমা তার সংযোগ ধরন ঘোষণা করে VPNType কী-তে, এমন একটি অভিধানের ভেতরে যার PayloadType হলো com.apple.vpn.managed। মানটি একটি সংক্ষিপ্ত টোকেন, যেমন IKEv2, IPsec, L2TP বা VPN, আর পেলোডের বাকি সব কিছু সেই টোকেন অনুসারেই ব্যাখ্যা হয়।
<key>PayloadType</key>
<string>com.apple.vpn.managed</string>
<key>VPNType</key>
<string>IKEv2</string>
<key>IKEv2</key>
<dict>
<key>RemoteAddress</key>
<string>vpn.head-office.example</string>
<key>RemoteIdentifier</key>
<string>ikev2.head-office.example</string>
</dict>এই অংশটি দৃষ্টান্তমূলক, ইনস্টলযোগ্য নয়: এটি একটি পেলোড অ্যারের একটি এন্ট্রি, যা বাস্তব স্থাপনার প্রয়োজনীয় প্রোফাইল মেটাডেটা ও শংসাপত্র থেকে ছাঁটা। এটি আকৃতির জন্য পড়ুন, বিষয়বস্তুর জন্য নয়। আরও লক্ষ্য করুন, RemoteAddress আর RemoteIdentifier ভিন্ন কাজের ভিন্ন ফিল্ড, এমনকি যখন কোনো স্থাপনা তাদের একই স্ট্রিং দেয়।
পুরোনো মান, যেমন PPTP, এখনও পুরোনো ফাইলে দেখা যেতে পারে, যদিও বর্তমান macOS নতুন কনফিগারেশনের জন্য এটি কোনো বিকল্প হিসেবে দেয় না। সংরক্ষিত প্রোফাইলে টোকেন পাওয়া প্রমাণ করে কী লেখা হয়েছিল, অপারেটিং সিস্টেম এখনও কী গ্রহণ করবে তা নয়।
কাস্টম ধরনে VPNSubType ও মালিক অ্যাপ দরকার
যখন VPNType হলো VPN, পেলোডকে অবশ্যই VPNSubType-ও বহন করতে হবে, যা সংযোগটি বাস্তবায়নকারী প্লাগ-ইন বা Network Extension প্রদানকারীকে চিহ্নিত করে। এই শনাক্তকারীই সংযোগটিকে নির্দিষ্ট ক্লায়েন্টে পাঠায়, তাই ভুল সাবটাইপ এমন প্রোফাইল তৈরি করে যা ইনস্টল হয় কিন্তু চালু হতে অস্বীকার করে।
অ্যাপ-এক্সটেনশন ভিত্তিক প্রদানকারীদের ক্ষেত্রে শনাক্তকারীটি অনুমান করা এক্সটেনশন নামের নয়, বরং ধারণকারী অ্যাপের; হাতে প্রোফাইল সম্পাদনার সময় লোকেরা সাধারণত এই বিষয়টিই ভুল করে। এমনকি সঠিক সাবটাইপও ক্লায়েন্টের বর্ণনা দেয়, তার ওয়্যার প্রোটোকল, প্রমাণীকরণ পদ্ধতি বা দূর-অ্যাক্সেস নীতির নয়।
তাই কাস্টম পেলোড আপনাকে বলে কোন সফটওয়্যার সংযোগটির মালিক, আর সামান্য কিছু। এটি কী নিয়ে দরকষাকষি করে জানতে সেই প্রদানকারীর নিজস্ব ডকুমেন্টেশন ও কনফিগার করা সেটিংস পড়ুন। অন্য প্রতিষ্ঠানের প্রোফাইল থেকে সাবটাইপ কপি করা কনফিগারেশন কৌশল নয়; এটি এমন এক অনুমান যা কেবল পার্স হয়ে যায়।
Mac আসলে যা কনফিগার করেছে তা তালিকাভুক্ত করুন
কোনো ফাইল পড়ার আগে সিস্টেমকে জিজ্ঞাসা করুন কী কী সেবা আছে ও তারা কোন অবস্থায় আছে। কমান্ড-লাইন দৃশ্যটি প্যানেলে ক্লিক করার চেয়ে দ্রুত এবং প্রতিটি এন্ট্রির পাশে ধরনটি ছাপায়।
scutil --nc list scutil --nc show "Office VPN"
প্রথম কমান্ড কনফিগার করা VPN সেবাগুলো তাদের বর্তমান অবস্থাসহ তালিকাভুক্ত করে, আর দ্বিতীয়টি নির্বাচিত সেবার সেটিংস ছাপায়, যার মধ্যে ধরন ও যে সার্ভার ঠিকানায় সেটি যোগাযোগ করবে তা থাকে। ওই ঠিকানাটি প্রত্যাশিত গেটওয়ের সঙ্গে মেলান, কারণ অবসরপ্রাপ্ত হোস্টের দিকে ইশারা করা পুরোনো এন্ট্রি একটি সাধারণ উত্তরাধিকার সমস্যা।
এই কমান্ডগুলো কনফিগারেশন ও অবস্থা দেখায়; এরা প্রমাণ করে না যে কোনো টানেল ট্রাফিক বহন করছে। সেবাটি সংযুক্ত না থাকলে আউটপুট কাজ করা সেশনের নয়, ইচ্ছার বর্ণনা দেয়। ট্রাফিক ছাড়া সংযুক্ত সেবা আবার ভিন্ন সমস্যা, সাধারণত রাউটিং বা DNS, প্রোটোকল ধরন নয়। এই তিনটি পর্যবেক্ষণ আলাদা রাখুন, নইলে রোগনির্ণয় আবার অনুমানে ফিরে যায়।
সংরক্ষিত সেটিংসকে জীবন্ত সেশন থেকে আলাদা রাখুন
সংরক্ষিত প্রোফাইল হলো ইচ্ছার ঘোষণা। এটি দেখায় না যে গেটওয়ে এখনও ওই সেবা দেয়, এই প্রোফাইলটিই সক্রিয়, বা কোনো সেশন সফলভাবে দরকষাকষি করেছে। এগুলো তিনটি আলাদা প্রশ্ন এবং প্রত্যেকটির নিজস্ব প্রমাণ আছে।
সক্রিয় সংযোগ ও গেটওয়ে যে পরিচয় উপস্থাপন করেছে তা শনাক্ত করতে মালিকের অবস্থা দৃশ্য বা ডায়াগনস্টিক টুলিং ব্যবহার করুন। পোর্ট স্ক্যান বা অসম্পর্কিত সাইটে দেখা একটি সার্টিফিকেট কোনোটিরই উত্তর দেয় না, আর সার্টিফিকেটের সাধারণ নাম প্রত্যাশিত দূরবর্তী শনাক্তকারীর সমান নয়।
সংরক্ষিত ধরন আর গেটওয়ে যা সমর্থন করে তার সঙ্গে না মিললে তার মালিকের কাছ থেকে একটি প্রতিস্থাপন প্রোফাইল নিন। ধরন স্ট্রিং বদলানো প্রোটোকলের মধ্যে শংসাপত্র অনুবাদ করে না, আর একটি প্রমাণীকরণ ব্যবস্থাকে অন্যটিতে পরিণত করে না। অনুমোদিত সহায়তা চ্যানেলের মাধ্যমে সারাংশটি ভাগ করুন, কারণ রপ্তানি করা কনফিগারেশন এমন শংসাপত্র ও ব্যক্তিগত কী বহন করতে পারে যা কোনো সহায়তা অনুরোধে কখনও লাগেনি।