হটস্পট ক্লায়েন্টের জন্য স্প্লিট টানেলিং অ্যাপভিত্তিক বাদ নয়
কোনো অ্যাপকে VPN থেকে বাদ দিলে শুধু ফোনটাই বদলায়। টিদার করা ল্যাপটপের নিজস্ব ফরওয়ার্ডিং নিয়ম দরকার, যা সোর্স, ডেস্টিনেশন ও NAT-এ মেলানো হয়।
একই রকম শোনানো দুটি দাবি এক নয়: «এই অ্যাপটি VPN থেকে বাদ দাও» এবং «আমার হটস্পটে থাকা ল্যাপটপের জন্য এই একটি ডেস্টিনেশন VPN-এর বাইরে পাঠাও»। প্রথমটি বদলায় ফোনের একটি সকেট কীভাবে নেটওয়ার্ক বেছে নেয়। দ্বিতীয়টি একটি ফরওয়ার্ডিং সিদ্ধান্ত বদলাতে হবে এমন একটি প্যাকেটের জন্য যা ফোন ইতিমধ্যেই গ্রহণ করার পর অন্য ডিভাইস থেকে এসেছে। দুটিকে গুলিয়ে ফেলা মানে হটস্পট ক্লায়েন্ট এমন একটি ব্যতিক্রম নিয়ে শেষ করে যা কেবল ফোনের নিজের ব্রাউজারেই প্রযোজ্য ছিল।
দুটি প্রশ্নের মালিক দুটি আলাদা সাবসিস্টেম
অ্যান্ড্রয়েড অ্যাপ নেটওয়ার্কিং ও টিদারিং আলাদা রাখে। অ্যাপের সকেটগুলো কানেক্টিভিটি স্ট্যাক নেটওয়ার্কে বরাদ্দ করে, আর একটি VPN অ্যাপ ঠিক করে তার নিজের কোন সকেটগুলো টানেলে ঢুকবে। টিদার করা ক্লায়েন্ট থেকে ফরওয়ার্ড করা প্যাকেট টিদারিং সাবসিস্টেম সামলায়, যা netd-এর কাছে ডাউনস্ট্রিম ইন্টারফেসে রুট, পলিসি নিয়ম ও অনুবাদ চায়।
কোনো অ্যাপ সকেট খোলার সময় অ্যাপভিত্তিক বাদ দেওয়া মূল্যায়ন করা হয়। ফরওয়ার্ড করা প্যাকেট ওই যাচাইয়ে কখনো পৌঁছায় না, কারণ এটি এই ডিভাইসের কোনো অ্যাপ সকেট থেকে উৎপন্ন হয়নি। দুটি সেটিং একে অন্যের বিকল্প হতে না পারার সম্পূর্ণ কারণ এটাই, এবং এটি কোনোটিরই বাগ নয়।
অ্যাপভিত্তিক বাদ দেওয়া আসলে কী বদলায়
একটি VpnService বিল্ডার addDisallowedApplication দিয়ে টানেলের বাইরে থাকা প্যাকেজের নাম দিতে পারে, অথবা addAllowedApplication দিয়ে ভেতরে অনুমোদিত একমাত্র প্যাকেজগুলোর নাম দিতে পারে। এরপর ওই অ্যাপগুলো অন্তর্নিহিত নেটওয়ার্কে সকেট খোলে, আর VPN বাকি সবকিছুর জন্য ডিফল্ট রুটের মালিক থাকে।
পরিধি সুনির্দিষ্ট: প্যাকেজের নিজের সকেট, এই ডিভাইসে, যতক্ষণ টানেল চালু থাকে। এটি ফরওয়ার্ড করা ট্রাফিক, দ্বিতীয় ডিভাইস, বা সিস্টেম টিদারিংয়ের পক্ষে যে প্যাকেট পাঠায় সে সম্পর্কে কিছুই বলে না।
এটিও ডেস্টিনেশন নিয়ন্ত্রণ নয়। ব্রাউজার বাদ দিলে ওই ব্রাউজার যে প্রতিটি ঠিকানায় পৌঁছায় তা বাদ পড়ে, যার মধ্যে সেই ঠিকানাও আছে যা আপনি টানেলের ভেতরে রাখতে চেয়েছিলেন। যখন দাবিটি অ্যাপের বদলে একটি ডেস্টিনেশনের নাম নেয়, তখন অ্যাপ সিলেক্টরই গঠনগতভাবে ভুল হাতিয়ার।
ফোনের কাছে টিদার করা প্যাকেট কেমন দেখায়
ক্লায়েন্টের প্যাকেট হটস্পট ইন্টারফেসে আসে ফোনের বরাদ্দ করা ব্যক্তিগত সোর্স ঠিকানা নিয়ে, ধরা যাক 192.168.43.20, এবং একটি পাবলিক ডেস্টিনেশন নিয়ে। এটি ফরওয়ার্ড করতে ফোনের দরকার আপলিংকের দিকে একটি রুট এবং একটি অনুবাদ নিয়ম, যাতে উত্তরগুলো ফেরার পথ খুঁজে পায়, কারণ ক্লায়েন্টের ব্যক্তিগত ঠিকানা সেলুলার নেটওয়ার্কে অর্থহীন।
অ্যান্ড্রয়েড এটি প্রকাশ করে পলিসি নিয়মে যা একটি রাউটিং টেবিল বেছে নেয়, আর নেটওয়ার্ক ও VPN বদলালে netd সংশ্লিষ্ট টেবিল ও নিয়ম আবার তৈরি করে। কোনো ফোরাম পোস্ট থেকে বা পুরোনো রিলিজের একই মডেল থেকে কপি করা টেবিল নম্বর, নিয়মের অগ্রাধিকার বা ইন্টারফেসের নাম টেকসই মালিকানা প্রতিষ্ঠা করে না। এই নতুন করে তৈরি হওয়াই হাতে লেখা নিয়ম এক ঘণ্টা কাজ করে পরের পুনঃসংযোগের পর থেমে যাওয়ার কারণ।
হটস্পট ব্যতিক্রমের আসলে যে পলিসি দরকার
কোনো নিয়মে হাত দেওয়ার আগে সিদ্ধান্তটি সোর্স, ডেস্টিনেশন ও অভীষ্ট পথ হিসেবে লিখুন। একটি অনুমোদিত ডেস্টিনেশনের ন্যূনতম রূপ এমন দেখায়:
| Source | Destination | Intended path |
|---|---|---|
| One authorized hotspot client | One approved public service address | Ordinary cellular uplink |
| The same client | All other covered destinations | Shared VPN |
| The phone's own apps | Their existing destinations | Unchanged phone policy |
দুই দিকই সম্পূর্ণ হতে হবে। সরাসরি শাখার দরকার বর্তমানে সক্রিয় সেলুলার আপলিংক দিয়ে ব্যবহারযোগ্য একটি রুট; VPN শাখার দরকার টানেল রুট এবং ফরওয়ার্ড করার অনুমতি। যেকোনো সোর্স অনুবাদ আপনার বেছে নেওয়া ইগ্রেসের সঙ্গে মিলতে হবে, কারণ টানেল ইন্টারফেসে প্রয়োগ করা NAT টানেলের ঠিকানা দেখায়, সেলুলারের নয়, আর তখন ফেরার পথ বেরোনোর পথের সঙ্গে মেলে না।
উত্তরগুলোকে ট্র্যাক করা অবস্থা বা স্পষ্ট রুটের মাধ্যমে একই ডাউনস্ট্রিম ক্লায়েন্টে পৌঁছাতে হবে, আর আউটবাউন্ড প্যাকেট কাউন্টার এর কিছুই প্রমাণ করে না। VPN-এর নিজের বাইরের ট্রান্সপোর্টকেও ব্যতিক্রমের পরিধির বাইরে রাখুন, নইলে টানেলের ক্যারিয়ার প্যাকেট ক্লায়েন্টের ওয়েব অনুরোধের জন্য লেখা পলিসি উত্তরাধিকারে পায়।
ধরা পড়া একটি ঠিকানা ডেস্টিনেশন নয়
ব্রাউজার থেকে পড়া একটি IPv4 ঠিকানা একটি স্ন্যাপশট। বড় সার্ভিসগুলো anycast বা ঘুরতে থাকা এজ ঠিকানার সেট থেকে উত্তর দেয়, অনেকগুলো ডুয়াল-স্ট্যাক, আর একটি লগইন প্রবাহ অথেন্টিকেশন ও টেলিমেট্রি হোস্টে পৌঁছাতে পারে যা পেজ কখনো দেখায় না। যে ঠিকানাটি আপনি দৈবক্রমে দেখেছেন তার চারপাশে তৈরি ব্যতিক্রম পরের বার সার্ভিস লোড ভারসাম্য করলেই ভেঙে যায়।
সার্ভিসের মালিকের নথিভুক্ত ঠিকানা, বা সে প্রকাশ করে এমন একটি রেঞ্জ ব্যবহার করুন, এবং দুই ঠিকানা পরিবারই হিসাবে রাখুন। দাবিটি যদি স্থিতিশীল সেট হিসেবে প্রকাশ করা না যায়, তাহলে এটি সম্ভবত ফোনে রাউটিং কৌশল নয়, সার্ভিসের জন্য পলিসি প্রশ্ন।
ডাউনস্ট্রিম দিক থেকে যাচাই করুন
তিনটি যাচাই, এই ক্রমে: ল্যাপটপ থেকে নির্বাচিত সার্ভিস, একটি সাধারণ ডেস্টিনেশন যা VPN-এর ভেতরে থাকতে হবে, আর একটি ফোন অ্যাপ যা অপরিবর্তিত থাকতে হবে। তারপর পুনঃসংযোগের পরে এবং আপলিংক বদলের পরে আবার করুন, কারণ ঠিক তখনই পলিসি টেবিলগুলো আবার তৈরি হয়।
ফোনের শেয়ারিং বাস্তবায়ন যদি পুনঃসংযোগ জুড়ে ওই চুক্তি ধরে রাখতে না পারে, তবে হ্যান্ডসেটে root নিয়ম জমাতে না গিয়ে নির্বাচনী পলিসি সমর্থিত একটি ডাউনস্ট্রিম রাউটারে সরান। একটি রাউটার স্থিতিশীল মালিকের সঙ্গে সোর্স ও ডেস্টিনেশন মিলানো প্রকাশ করতে পারে, আর টিদারিং মডিউলের ডকুমেন্টেশন হলো ফোন আসলে কী করছে তার সঠিক সূত্র।