কোন macOS টুল একটি অ্যাপকে শুধু VPN দিয়ে যেতে বাধ্য করতে পারে?
শুধু-VPN সীমার জন্য দরকার পথ এবং প্রত্যাখ্যান, দুটোই। প্রতি-অ্যাপ প্রোফাইল, প্রক্সি, ফিল্টার ও PF তুলনা করুন, তারপর আপনার দরকারের ওই একটি অ্যাপ পরীক্ষা করুন।
একটি প্রয়োজনীয়তা নথিতে এক লাইন—“এই অ্যাপটি VPN ব্যবহার করতে পারে, আর কিছু নয়”—চুপচাপ দুটি প্রক্রিয়া দাবি করে, যা কোনো একক সুইচ দেয় না। ট্রাফিকের দরকার উদ্দিষ্ট টানেল দিয়ে যাওয়ার পথ, আর যে ট্রাফিক সরাসরি বেরিয়ে যেত তা প্রত্যাখ্যান করা দরকার। যে টুলগুলো এর একটি ভালো করে আর অন্যটি একেবারেই করে না, সেগুলো সাধারণ, তাই যে তুলনা কেবল জিজ্ঞেস করে কোনো কিছু ব্লক করতে পারে কি না, তা আত্মবিশ্বাসের সঙ্গে প্রশ্নের অর্ধেকের উত্তর দেয়। আগে সীমাটি লিখে নিন, তারপর এমন উপাদান বাছুন যা তার দুই অর্ধেকই ঢেকে রাখে।
একটি বাক্যের ভেতরে লুকানো দুটি প্রয়োজনীয়তা
স্টিয়ারিং হলো সেই অংশ যা সংযোগকে টানেল বা প্রক্সিতে রাখে। প্রত্যাখ্যান হলো সেই অংশ যা একই সংযোগকে অন্য কোনো পথে বেরোতে বাধা দেয়। ভিন্ন ভিন্ন উপাদান এগুলো বাস্তবায়ন করে, তারা ভিন্নভাবে ব্যর্থ হয়, এবং একটি পণ্য একটিতে দুর্দান্ত হতে পারে অথচ অন্যটি সম্পর্কে কিছুই না বলে:
| Approach | Steers traffic | Refuses direct egress | Knows the app identity |
|---|---|---|---|
| Per-app VPN profile | Yes, for the apps it names | Only if a filter or firewall also blocks | Yes, within its own rules |
| Application proxy setting | Partly, for requests that honour it | No | No |
| Content filter | No | Yes | Yes, if the filter is written that way |
| Local PF ruleset | No | Yes, by address and port | Not reliably |
সারণিটিকে র্যাঙ্কিং নয়, চেকলিস্ট হিসেবে পড়ুন। কোনো সারি দুই মাঝের কলামই ভরে না, আর যে সারিগুলো সেগুলো ঢাকে তারা হলো দুইটি সহযোগী উপাদান: একটি পথের মালিক, অন্যটি প্রত্যাখ্যানের। পরিচয়ের কলামটি ভিন্ন কারণে গুরুত্বপূর্ণ, কারণ যে নিয়ম অ্যাপটির নাম বলতে পারে না, সে ওই অ্যাপ সম্পর্কিত নিয়ম প্রয়োগ করতে পারে না। আপনি যা-ই মোতায়েন করুন, তাকে তিনটিরই উত্তর দিতে হবে, নইলে প্রয়োজনীয়তা নথির সীমা মেশিনের সীমা নয়।
একা স্টিয়ারিং একটি বেরোনোর পথ খোলা রাখে
অ্যাপ্লিকেশন প্রক্সি সেটিং প্রত্যাখ্যানহীন স্টিয়ারিংয়ের সবচেয়ে স্পষ্ট উদাহরণ। এটি এমন অ্যাপের অনুরোধ স্টিয়ার করতে পারে যা সিস্টেম প্রক্সি মানে, আর অন্য কিছুই ঢাকে না: একটি হেল্পার প্রসেস, একটি আপডেটার, একটি ব্যাকগ্রাউন্ড সার্ভিস বা ভিন্ন প্রোটোকল ওই পছন্দ না পড়েই নিজের পথে যেতে পারে। তাই একটি প্যানেলে SOCKS এন্ডপয়েন্ট বাছাই করা অ্যাপটির জন্য সরাসরি-নির্গমন-নিষিদ্ধ নীতি তৈরি করে না। প্রয়োজনীয়তাটি যদি সামগ্রিকভাবে অ্যাপটি নিয়ে হয়, তবে জিজ্ঞেস করুন নিয়মটি আসলে কোন উপাদানগুলোকে চিহ্নিত করে।
প্রতি-অ্যাপ VPN প্রোফাইল প্রক্সির চেয়ে ভালো স্টিয়ার করে, কারণ প্ল্যাটফর্ম ঠিক করে কোন অ্যাপগুলো টানেলে ঢোকে প্রতিটি অ্যাপ নিজে সিদ্ধান্ত নেওয়ার বদলে। তবুও এটি কিছু প্রত্যাখ্যান করে না: প্রোফাইল একটি পথ দেয়, আর যে ট্রাফিক এর সঙ্গে মেলে না তা সাধারণ পথ নেয়। এই ফাঁকটিই ঠিক সেই জায়গা যেখানে দ্বিতীয় উপাদান তার জায়গা অর্জন করে, আর তাই একক সুইচের মতো দেখতে পণ্য সাধারণত দুটি হয়।
একা প্রত্যাখ্যান অ্যাপটি ভেঙে দেয়
Apple-এর কনটেন্ট-ফিল্টার ডকুমেন্টেশন নেটওয়ার্ক স্ট্যাক দিয়ে ট্রাফিক যাওয়ার সময় তার উপর একটি অনুমোদন-বা-ব্লক রায়ের বর্ণনা দেয়। সেই রায় টানেল নয়, প্রক্সি সংযোগও নয়, কারণ এটি ঠিক করে কিছু চলতে পারবে কি না, কোথায় যাবে তা নয়। একা একটি ফিল্টার প্রত্যাখ্যান নিখুঁতভাবে প্রয়োগ করে আর অ্যাপটিকে অব্যবহারযোগ্য রেখে দেয়, পরিচ্ছন্ন লগ আর কোনো ব্যাখ্যা ছাড়াই। ফিল্টার রায় একটি সংযোগ থামাতে পারে কিন্তু কখনোই টানেল দেয় না, তাই এটিকে স্টিয়ারিংয়ের সঙ্গে জোড়া দেওয়াই নকশার সিদ্ধান্ত, বাড়তি বিকল্প নয়।
স্থানীয়ভাবে পরিচালিত PF নিয়মসেট সেই বর্ণালীর অন্য প্রান্তে বসে। এটি প্রশাসকের মালিকানার একটি মেশিনে বৈধ সহায়তা-সিদ্ধান্ত, এবং এটি স্বয়ংক্রিয়ভাবে একটি বিতরণযোগ্য পণ্যের ভিত্তি নয়, কারণ যে নিয়মসেটের মালিক, সে অন্য ফায়ারওয়াল ব্যবহারকারীদের সঙ্গে তার মিথস্ক্রিয়া, তার আপগ্রেড পথ এবং কোনো নিয়ম ভুল হলে তার পুনরুদ্ধারেরও মালিক। পণ্যে PF যোগ করলে সেই মালিকানা-প্রশ্নটি মুছে যায় না; এটি সেটিকেই সংজ্ঞায়িত করে।
মোতায়েনই ঠিক করে নিয়মটি কালও থাকবে কি না
Apple প্ল্যাটফর্মে একটি Network Extension কীভাবে মোতায়েন হয় তা নির্ভর করে প্রোভাইডারের ধরন, প্যাকেজিং এবং আপনার সামনের OS সংস্করণের উপর। macOS-এ একটি অ্যাপ এক্সটেনশন ব্যবহারকারী প্রসঙ্গে চলে এবং সেই ব্যবহারকারী লগআউট করলে শেষ হয়, আর একটি সিস্টেম এক্সটেনশনের থাকে সেশন-নিরপেক্ষ বৈশ্বিক প্রসঙ্গ। সুরক্ষাকে লগআউটের পরেও টিকতে হলে সেই পার্থক্যই পুরো নকশা, পাদটীকা নয়। আচরণের প্রতিশ্রুতি দেওয়ার আগে মোতায়েনের পথ নিশ্চিত করুন, কারণ একই কোড কোন এক্সটেনশন ধরন পাঠানো হচ্ছে তার উপর নির্ভর করে ভিন্নভাবে পৌঁছায়।
সোর্সের প্রাপ্যতা প্রয়োগ থেকে আলাদা বিষয়। একটি রিপোজিটরি পড়লে বোঝা যায় কিছু কীভাবে বাস্তবায়িত, কিন্তু ইনস্টল করা বাইনারি এই মেশিনে কী করতে পারবে তা নয়। সাইনিং, ইনস্টলেশন ও অনুমোদন এখনও প্রযোজ্য, আর অচল কার্নেল এক্সটেনশন বা লাইব্রেরি-ইনজেকশন কৌশল ঘিরে তৈরি নির্দেশনা ভিন্ন প্ল্যাটফর্ম ও ভিন্ন ঝুঁকির অবস্থান বোঝায়, একসময় যত ভালোই কাজ করে থাকুক।
অ্যাপটির নাম উল্লেখ করা একটি গ্রহণযোগ্যতা-পরীক্ষা
অ্যাপটি নিজে করে এমন একটি কাজ বাছুন, যে ঠিকানায় পৌঁছানো উচিত এবং ঠিকানাটি IPv4 না IPv6 তা লিখে রাখুন, তারপর অনুমোদিত টানেলহীন অবস্থায় একই কাজটি আবার করুন। দ্বিতীয় চালানায় ঘোষিত প্রত্যাখ্যান আসতে হবে, নীরব সরাসরি পুনঃচেষ্টা নয়। এটিই সেই অর্ধেক যা মানুষ অনির্দিষ্ট রাখে, আর একমাত্র অর্ধেক যা প্রমাণ করে প্রত্যাখ্যান আদৌ আছে। প্রথমে টানেল থাকা অবস্থায় চালান, যাতে দুটি ফলাফলের পার্থক্য কেবল অনুপস্থিত টানেল থেকেই আসতে পারে।
তারপর প্রয়োজনীয়তায় উল্লিখিত রূপান্তরগুলো ধরে এগোন: অ্যাপ পুনরায় চালু, হেল্পার চালু হওয়া, টানেল পুনঃসংযোগ, মেশিনের নেটওয়ার্ক বদল, আর প্রযোজ্য ক্ষেত্রে লগআউট বা রিবুট। ব্রাউজারের পাবলিক-IP পাতা অন্য অ্যাপের সকেটের পরীক্ষা নয়, তাই এটি এটির জায়গা নিতে পারে না। যেখানে কোনো সমর্থিত মোতায়েন অ্যাপের প্রকৃত আচরণ ঢাকে না, সেখানে স্পষ্ট গেটওয়ে ও বিকল্প নির্গমনহীন একটি অনুমোদিত বিচ্ছিন্ন পরিবেশ হলো নিজস্ব ব্যবস্থাপনা-ব্যয়সহ একটি সংযত-রাখার সিদ্ধান্ত, চেকবক্সের বদল নয়।
চারটি এন্ট্রি লিখে শেষ করুন: অ্যাপটি কোন উপাদানে গঠিত, স্টিয়ারিংয়ের মালিক কে, প্রত্যাখ্যানের মালিক কে, এবং কোন অবস্থায় নিয়মটি এখনও প্রযোজ্য থাকতে হবে। একটি পাবলিক রিপোজিটরি বাছাইয়ের একটি মানদণ্ড হতে পারে, কিন্তু এটি চারটির একটি নয়, আর সেই এন্ট্রিগুলোই ঠিক করে কোনো টুল নেটওয়ার্কিং প্রয়োজনীয়তা পূরণ করে কি না।