TAP নাকি TUN? Android-এর OpenVPN ক্লায়েন্ট ও ব্রিজড সার্ভার
TAP Ethernet ফ্রেম বহন করে, TUN IP প্যাকেট বহন করে, আর Android অ্যাপ শুধু দ্বিতীয় ধরনটাই পায়। দুটো তুলনা করুন, তারপর সার্ভার দিকটা ঠিক করুন।
ল্যাপটপে যে প্রোফাইল কাজ করে, ফোনে সেটি ব্যর্থ হয়। স্পষ্ট পদক্ষেপ হলো ক্লায়েন্ট কনফিগে একটি শব্দ বদলানো। সেই শব্দ কাজে লাগবে না, কারণ দুই প্রান্ত একই ধরনের ট্র্যাফিকের কথা বলছে না।
TAP Ethernet ফ্রেম বহন করে। TUN IP প্যাকেট বহন করে। Android VPN অ্যাপকে একটি IP ইন্টারফেস দেওয়া হয়, ফলে কনফিগ যা-ই বলুক, দুটো বিন্যাসের একটি সম্ভব হয় আর অন্যটি হয় না।
তুলনাটি সংক্ষিপ্ত, কিন্তু এটি ঠিক করে আপনি ফোনেই এটি সারাতে পারবেন, নাকি সেবাটাই বদলাতে হবে।
আলাদা পেলোডযুক্ত দুই ধরনের টানেল
TAP ইন্টারফেস Ethernet অ্যাডাপ্টারের মতো আচরণ করে। এটি ফ্রেম বহন করে, অর্থাৎ ARP, ব্রডকাস্ট এবং IP-এর নিচে একটি LAN যা বহন করে সবকিছু। এটাই ব্রিজিং সম্ভব করে: টানেল একটি ব্রডকাস্ট ডোমেইন বাড়ায়, আর ক্লায়েন্টরা নিজেদের সুইচে প্লাগ করা মনে করে।
TUN ইন্টারফেস তার কাছে ঠিকানা-করা IP প্যাকেট বহন করে। আলোচনার জন্য কোনো লিংক লেয়ার নেই, ARP নেই, ব্রডকাস্ট নেই। রাউটিং ঠিক করে টানেলে কী ঢুকবে, আর সার্ভার-সাইড কনফিগ ব্রিজের বদলে একটি সাবনেট ব্যবহার করে।
দুই প্রান্তকে একমত হতে হবে তারা এর মধ্যে কোনটি করছে। এক দিকে dev tap থেকে dev tun-এ বদলালে সেবাটি রূপান্তরিত হয় না; বরং এমন ক্লায়েন্ট তৈরি হয় যে রাউটেড টানেল আশা করে আর সার্ভার তখনও ফ্রেম পাঠায়, এবং হ্যান্ডশেক সফল হতে পারে অথচ ব্যবহারযোগ্য কিছুই পার হয় না।
Android আসলে অ্যাপকে কী দেয়
প্ল্যাটফর্মের VpnService API একটি অ্যাপকে IP প্যাকেটের জন্য ভার্চুয়াল ইন্টারফেস দেয়, যা ঠিকানা, রুট ও MTU দিয়ে কনফিগার করা। ওই API-তে কোনো Ethernet অ্যাডাপ্টার নেই, আর অ্যাপের পক্ষে একটি বানানোর উপায়ও নেই।
এই কারণেই OpenVPN Connect Android-এ TAP ব্রিজিংয়ের বদলে রাউটেড TUN সংযোগের সমর্থন নথিভুক্ত করে। Android FAQ হলো এই সীমার ক্লায়েন্ট-দিকের বিবৃতি, এবং এটি প্ল্যাটফর্ম API-র সঙ্গে মেলে।
রুট নেটওয়ার্কিং টুল, কাস্টম ফার্মওয়্যার বা স্পষ্ট অনুবাদ স্তর প্রয়োগ করা পণ্য ভিন্ন বিন্যাস। সাধারণ ক্ষেত্রটিই পরিকল্পনার ভিত্তি: এমন অ্যাপ যা আপনার ফাইল আমদানি করতে পারে এবং সাধারণ ব্যবহারকারী হিসেবে চলতে পারে, একটি IP ইন্টারফেস নিয়ে আর তার নিচে কিছুই নেই।
তবুও চেষ্টা করলে কেমন দেখায়
সংযোগ সাধারণত প্রতিষ্ঠিত হয়। এটাই ব্যর্থতাকে বিভ্রান্তিকর করে: ক্লায়েন্ট সংযুক্ত বলে জানায়, সার্ভার লগে একটি পিয়ার দেখায়, অথচ কোনো অ্যাপ্লিকেশন কাজ করে না।
ফোনের নির্ধারিত ঠিকানায় পাঠানো ট্র্যাফিক পৌঁছায় না, কারণ সার্ভার ফ্রেমগুলো এমন MAC ঠিকানায় ব্রিজ করে যা ফোনের কখনো ছিল না। ব্রডকাস্ট-নির্ভর ডিসকভারি খালি থাকে। যদি LAN ব্রিজের ওপর DHCP-র ওপর নির্ভর করে, ফোন ওইভাবে লিজ পাবে না, আর ব্রিজড সাবনেটে হাতে দেওয়া ঠিকানা তবুও অনুপস্থিত ইন্টারফেস তৈরি করে না।
কিছু ক্লায়েন্ট আরও আগে ব্যর্থ হয়, প্রোফাইল আমদানির সময়, যখন এমন ডিভাইসের ধরন দেখে যা তারা বাস্তবায়ন করতে পারে না। দুই আচরণই একই কথা বোঝায়, আর রুট যোগ করা, DNS বদলানো বা টানেলের ঠিকানা-পরিসর বাড়িয়ে কোনোটিই ঠিক হয় না।
সার্ভার দিককে কী বদলাতে হবে
সমাধানটি VPN সেবা চালানো ব্যক্তির, এবং এটি সাধারণত স্থানান্তর নয়, সংযোজন। একটি রাউটেড ডিভাইস, নিজস্ব ক্লায়েন্ট সাবনেট এবং ঠিকানা বণ্টন করে ফোনগুলোর প্রয়োজনীয় রুট পাঠায় এমন সার্ভার-সাইড কনফিগ নিয়ে দ্বিতীয় একটি OpenVPN ইনস্ট্যান্স চালান। বিদ্যমান ব্রিজড ইনস্ট্যান্স Ethernet সত্যিই প্রয়োজন এমন ডিভাইসগুলোর সেবা দিতে থাকে।
দুটি খুঁটিনাটি একে বাস্তবে কাজ করায়। নতুন ক্লায়েন্ট সাবনেটের জন্য LAN-এর VPN হোস্টের দিকে ইঙ্গিত করা একটি রিটার্ন রুট দরকার, নইলে উত্তর কখনো ফিরবে না। আর টানেল হোস্টের ফায়ারওয়ালকে টানেল ইন্টারফেস ও LAN-এর মধ্যে ফরওয়ার্ড করতে হবে, যা সবচেয়ে বেশি বাদ পড়ে যখন হোস্ট থেকেই পরীক্ষা সফল হয়।
যদি অপারেটর সেবা যোগ করতে না পারে, বিকল্প হলো এমন ডিভাইস যা ব্রিজে যোগ দিতে পারে, অর্থাৎ ফোনের পক্ষে কাজ করা একটি ল্যাপটপ বা রাউটার। এটি নিজস্ব ব্যবস্থাপনা খরচসহ একটি অস্থায়ী উপায়, Android কনফিগ নয়।
টানেল নয়, অ্যাপ্লিকেশন থেকে সিদ্ধান্ত নিন
ফোনকে আসলে কী পর্যন্ত পৌঁছাতে হবে জিজ্ঞেস করুন, তারপর তা ম্যাপ করুন। নাম বা ঠিকানা দিয়ে পৌঁছানো ফাইল শেয়ার বা ইন্ট্রানেট সাইট একটি IP প্রয়োজনীয়তা, আর DNS নামটি সমাধান করলে ও রুটটি থাকলে রাউটেড টানেল তা পূরণ করে। স্থানীয় ব্রডকাস্ট ডোমেইন ব্রাউজ করা ডিসকভারি টুল IP প্রয়োজনীয়তা নয়, আর যতই রাউটিং দিন তা ভরে উঠবে না।
| Requirement | Tunnel that satisfies it |
|---|---|
| File server or intranet by hostname | Routed TUN, with working DNS |
| Broadcast or ARP-based discovery | Ethernet bridging, so not an ordinary Android client |
| Multicast delivery | Bridging or an explicit multicast relay |
| One application to one address | Routed TUN, narrowest possible route |
সেই টেবিলটিই পাঠানোর অনুরোধ। অ্যাপ্লিকেশনটির নাম বলুন, এটি যে ঠিকানা বা নাম ব্যবহার করে তা বলুন, এবং এটি ডিসকভারির ওপর নির্ভর করে কি না তা বলুন। অপারেটর সেই বিবরণ নিয়ে কাজ করতে পারে, যা সংযুক্ত হয় না এমন ফোন নিয়ে কেউ করতে পারে না।
সবশেষে, প্রতিটি ক্লায়েন্টকে LAN অ্যাডাপ্টারের নকল করতে বাধ্য করার বদলে যে ডিভাইসগুলোর প্রয়োজন সেগুলোর জন্য TAP সেবাটি রাখুন। স্পষ্ট উদ্দেশ্যযুক্ত দুটি সেবা সবার জন্য আধা-কাজ করা একটির চেয়ে সহজে সহায়তা করা যায়।