প্রতি অ্যাপে VPN নাকি split tunnel? একটি Mac রুট কী ঠিক করতে পারে

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

নির্বাচক গন্তব্য, কখনো প্রক্রিয়া নয়

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

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

সাধারণ split tunnel আসলে কী দেয়

split tunnel ব্যক্তিগত প্রিফিক্সের জন্য রুট ইনস্টল করে এবং বাকি সবকিছু ভৌত পথে রেখে দেয়। সাধারণত অনুরোধের অর্থ এটাই: টানেল দিয়ে অফিস সার্ভারে পৌঁছানো, প্রকাশ্য ব্রাউজিং সরাসরি রাখা। এটি সহজ, প্রতিটি সাধারণ ক্লায়েন্ট এটি সমর্থন করে, এবং অন্য যেকোনো রুটের মতো একই ব্যবস্থায় এটি প্রয়োগ হয়। নির্দিষ্ট গন্তব্য route -n get দিয়ে যাচাই করুন, ডিফল্ট রুট পড়ার বদলে, কারণ split tunnel প্রায়ই ডিফল্ট রুটটিকে অক্ষত রাখে।

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

macOS-এ প্রতি-অ্যাপ VPN কী দাবি করে

macOS-এ সত্যিকারের প্রতি-অ্যাপ VPN হলো একটি Network Extension বৈশিষ্ট্য যা একটি কনফিগারেশন প্রোফাইল চালায়। একটি ব্যবস্থাপনা পেলোড নির্বাচিত অ্যাপকে একটি VPN কনফিগারেশনের সঙ্গে যুক্ত করে, এবং সিস্টেম পরে সেই অ্যাপগুলোর ট্রাফিক সেই অনুযায়ী রুট করে। এটি একটি ব্যবস্থাপিত স্থাপনা, যার অর্থ MDM, স্বাক্ষরিত প্রোফাইল এবং একজন প্রশাসক যিনি দুটোরই মালিক।

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

MDM ছাড়া অ্যাপ-স্তরের বিচ্ছিন্নতার তিন পথ

যেখানে ব্যবস্থাপনা নেই, সেখানে প্রক্সি হলো বাস্তব উত্তর। অ্যাপের নিজের প্রক্সি কনফিগারেশন সেট করুন, অথবা এমন একটি PAC ফাইল ব্যবহার করুন যা কেবল সেই অ্যাপের জন্য গন্তব্য ও প্রোটোকল অনুযায়ী বেছে নেয়।

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

অনুরোধ এমনভাবে লিখুন যেন উত্তর স্পষ্ট হয়

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

বহিষ্কৃত অ্যাপের ক্ষেত্রটি স্পষ্টভাবে অন্তর্ভুক্ত করুন। যে ক্লায়েন্ট কোনো অ্যাপের সুরক্ষিত পথ অনুপলব্ধ হলে অ্যাপটি থামিয়ে দেয়, সে সেই ক্লায়েন্টের চেয়ে ভিন্নভাবে আচরণ করে যে অ্যাপটিকে ভৌত ইন্টারফেসে ফিরে যেতে দেয়, এবং ব্যবহারকারীরা সেই পার্থক্য সঙ্গে সঙ্গে টের পান। টিকিটে প্রত্যাশার নাম দিন। তারপর আসল মেশিনে যাচাই করুন, কারণ একই পণ্য macOS-এ Windows-এর চেয়ে প্রায়ই ভিন্নভাবে আচরণ করে, এবং তার macOS নথিই তার সেটিংস কী করে সে সম্পর্কে একমাত্র নির্ভরযোগ্য উৎস।