অ্যাপ-ভিত্তিক ও গন্তব্য-ভিত্তিক স্প্লিট টানেলিং: কোনটি বেছে নেবেন

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

দুটি নিয়ম ভিন্ন স্তরে কাজ করে

অ্যাপ নিয়ম নেটওয়ার্ক স্তরের উপরে প্রয়োগ হয়, অপারেটিং সিস্টেম প্রেরককে যে পরিচয় দেয় তার বিপরীতে। Android-এ সেটি প্যাকেজের পেছনের UID, এবং VPN সেবা প্রতি UID-তে সিদ্ধান্ত নেয় ট্রাফিক টানেলে ঢুকবে কি না। গন্তব্য সম্পর্কে কিছুই জিজ্ঞাসা করা হয় না, তাই নির্বাচিত অ্যাপ যেকোনো কিছুতে পৌঁছাতে পারে এবং অন্য কোনো অ্যাপ অভ্যন্তরীণ নেটওয়ার্কে পৌঁছাতে পারে না।

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

অ্যাপ নিয়ম মোবাইল ক্লায়েন্ট ও পরিচালিত এজেন্টের জন্য উপযুক্ত

Android সরাসরি পছন্দ দেয়: VpnService.Builder.addAllowedApplication() ও addDisallowedApplication() প্যাকেজ নাম নেয় এবং প্রতি UID-তে সিদ্ধান্ত প্রয়োগ করে, যেমনটি Android-এর VPN ডেভেলপার গাইডে বর্ণিত। iOS-এ বান্ডেল আইডেন্টিফায়ারভিত্তিক প্রতি-অ্যাপ VPN নিয়মের মাধ্যমে সমতুল্য ব্যবস্থা আছে, যা সাধারণত হাতে লেখার বদলে MDM প্রোফাইল দিয়ে দেওয়া হয়।

ডেস্কটপ ক্লায়েন্টই দুর্বল জায়গা। বেশিরভাগ Windows ও macOS VPN ক্লায়েন্ট গন্তব্য অনুযায়ী রাউট করে এবং প্রতি-প্রক্রিয়া নির্বাচক כלל দেয় না, কারণ টানেল ড্রাইভার প্রক্রিয়া নয়, প্যাকেট দেখে। ল্যাপটপে একটি অ্যাপ্লিকেশন টানেল করার উপর যদি আপনার পরিকল্পনা নির্ভর করে, তবে তা ঘিরে নকশা করার আগে ক্লায়েন্টের প্রকৃত সামর্থ্য যাচাই করুন; হতে পারে আপনি গন্তব্য তালিকা আর দ্বিতীয় মেশিনের মধ্যে বেছে নিচ্ছেন।

মানুষ যে সংশ্লিষ্ট বিষয়টি মিস করে: ওই প্ল্যাটফর্মে রাউট দিয়ে অ্যাপ নিয়ম নকল করা যায় না। অ্যাপের সার্ভারের জন্য হোস্ট রাউট যোগ করলে সবার ট্রাফিক সেই সার্ভারে টানেল হয়ে যায়, ব্রাউজার ও আপডেটারসহ।

গন্তব্য নিয়ম সাবনেট তালিকা ও সাইট পৌঁছানোর জন্য উপযুক্ত

WireGuard মডেলটি স্পষ্ট করে। AllowedIPs হলো ক্রিপ্টোকি রাউটিং: যে অভ্যন্তরীণ প্যাকেটের গন্তব্য কোনো পিয়ারের তালিকার ভিতরে পড়ে, তা সেই পিয়ারের কাছে এনক্রিপ্ট হয়, আর বাকি সব স্বাভাবিক পথে এনক্রিপশন ছাড়াই বের হয়। নাম দেওয়ার মতো কোনো প্রক্রিয়া নেই এবং কী অন্তর্ভুক্ত তা নিয়ে কোনো অস্পষ্টতা নেই।

OpenVPN পুশ করা রাউট টেবিলের মাধ্যমে একই জায়গায় পৌঁছায়। route-nopull সার্ভারকে রাউট নির্ধারণ করা থেকে থামায়, এরপর ক্লায়েন্ট-সাইড route 10.20.0.0 255.255.0.0 vpn_gateway ঠিক অফিস প্রিফিক্স কভার করে। IPv6 এই প্রতিটি ক্লায়েন্টে আলাদা বিবৃতি, আর তা ভুলে যাওয়াই সঠিক দেখতে IPv4 স্প্লিটের চারপাশে লিক করার সবচেয়ে সাধারণ উপায়।

হোস্টনেম কোনো রাউট নয়। প্রোফাইল যদি ডোমেইন ফিল্ড দেয়, তবে এটিকে ক্লায়েন্ট একবার রিজলভ করা নাম হিসেবে ধরুন, স্থায়ী ঠিকানা-পরিসর হিসেবে নয়; কনটেন্ট ডেলিভারি নেটওয়ার্ক ও লোড ব্যালেন্সার কাল ভিন্ন ঠিকানা দেবে।

যেখানে দুই মডেলই ভাঙে: সহায়ক প্রক্রিয়া, শেয়ার্ড সেবা, রিজলভার

সহায়ক প্রক্রিয়া অ্যাপ নিয়ম ভাঙে এমনভাবে যা সার্ভারের ত্রুটির মতো দেখায়। ব্রাউজারের আপডেটার, ক্র্যাশ রিপোর্টার, SYSTEM হিসেবে চলা সিঙ্ক সেবা এবং অন্য প্যাকেজে এমবেড করা WebView সবই আলাদা পরিচয়, তাই ব্রাউজারটি টানেল করলে প্রকৃত অনুরোধটি টানেলের বাইরে থেকে যেতে পারে। উল্টোটাও সমান বিভ্রান্তিকর: বাদ দেওয়া কোনো অ্যাপ যদি টানেল করা প্রক্রিয়ার ভিতরের একটি শেয়ার্ড লাইব্রেরি কল করে, তার ট্রাফিক তবুও টানেল হয়ে যায়।

গন্তব্য নিয়ম শেয়ার্ড সেবা ও নামে ভাঙে। ফাইল শেয়ার, প্রিন্টার, অভ্যন্তরীণ DNS ও লাইসেন্সিং সার্ভার সবই ঠিকানায় থাকে, তাই এক-অ্যাপ টানেল ব্রাউজারকে অ্যাক্সেস দেয় অথচ ম্যাপ করা ড্রাইভ মৃত থাকে। এই কভারেজ পার্থক্য কোনো মডেলের বাগ নয়, কিন্তু এজন্যই এক-অ্যাপ টানেল এতবার VPN চালু আর শেয়ারটি নেই তৈরি করে।

রিজলভার দুটিকেই কাটে। ক্লায়েন্ট অভ্যন্তরীণ DNS সার্ভার সেট করলেও অপারেটিং সিস্টেম যদি পাবলিক রিজলভারে DNS over HTTPS ব্যবহার করে, উত্তর টানেলের বাইরে থেকে আসে এবং গন্তব্য নিয়ম হয়তো কখনো মিলবে না। নিয়মটি ভুল বলে সিদ্ধান্তে পৌঁছানোর আগে দেখুন কোন রিজলভার প্রকৃতপক্ষে উত্তর দিয়েছে, আর ক্লায়েন্টের দিকে নিশ্চিত করুন সে টানেল রিজলভার আদৌ ইনস্টল করেছে কি না। যে স্প্লিট DNS-কে টানেলের বাইরে রাখে তা রাউটিং টেবিলে নিখুঁত দেখায় এবং তবুও প্রতিটি অভ্যন্তরীণ নামে ব্যর্থ হয়।

রানবুক: বেছে নিন, প্রয়োগ করুন, যাচাই করুন

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

যত সংকীর্ণ রূপ প্রকাশ করতে পারেন তা প্রয়োগ করুন, তারপর ক্লায়েন্টের স্টেটাস আইকন নয়, রাউটিং টেবিলকে জিজ্ঞেস করে যাচাই করুন:

ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40

প্রথম দুই লাইন বাস্তব গন্তব্য যে ইন্টারফেস ব্যবহার করবে তা নাম দেয়; wg show কনফিগার করা প্রিফিক্স তালিকা ছাপে; Windows-এ Find-NetRoute প্যাকেট পাঠানোর সময় স্ট্যাক যে প্রশ্নের উত্তর দেবে সেই একই প্রশ্নের উত্তর দেয়। ইন্টারফেস যদি টানেল হয়, নিয়ম মিলেছে।

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