আপনার আরও একটি ব্যক্তিগত সাবনেট দরকার — ধরুন 10.60.0.0/24 — যা প্রোফাইলে এখন নেই। ল্যাপটপে আপনি একটি রুট যোগ করে এগিয়ে যেতেন। Android-এ VPN একটি অ্যাপ, tun ডিভাইসটি সেই অ্যাপের, এবং রুট ছাড়া সম্পাদনা করার মতো কোনো রাউটিং টেবিল আপনার নেই। রুটটি থাকতেই হবে, তবে সেটি ক্লায়েন্ট যে প্রোফাইল লোড করে তার ভেতরে যায়, এবং তা কেবল তখনই কাজ করে যখন অপর প্রান্ত সম্মত হয়। এখানে আছে সম্পাদনা, পুনঃসংযোগ, সার্ভারের দিক এবং রোলব্যাক।

সম্পাদনার আগে: একটি রুট কী করতে পারে আর কী করতে পারে না

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

আগে সেই সম্মতি নিন, নেটওয়ার্কের মালিক থাকলে লিখিতভাবে। তারপর লক্ষ্য করুন আপনি কী করছেন না: আপনি ফোনকে ওই LAN-এর ভেতরে কোনো ঠিকানা দিচ্ছেন না, সার্ভারের লিসেনার বদলাচ্ছেন না, এবং হোস্টনাম দিয়ে কোনো সাইট বাছছেন না। এগুলো চারটি আলাদা পরিবর্তন এবং কেবল প্রথমটি আপনার।

The route gives youThe route does not give you
A destination prefix associated with the tunnelPermission to forward at the gateway
A path for the phone's own trafficA return route on the target host
A scope for the client's virtual interfaceA name in DNS, or HTTPS identity

ক্লায়েন্ট যে প্রোফাইলটি সত্যিই লোড করে সেটিই সম্পাদনা করুন

সাধারণ OpenVPN অপশন টেক্সট আমদানি করে এমন সামঞ্জস্যপূর্ণ ক্লায়েন্টের জন্য যোগ করার জিনিস এক লাইন:

route 10.60.0.0 255.255.255.0

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

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

প্রোফাইলে ইতিমধ্যে route-nopull থাকলে সার্ভার থেকে কোনো রুট ইনস্টল হয় না এবং ফোনের প্রয়োজনীয় প্রতিটি প্রিফিক্স আলাদাভাবে তালিকাভুক্ত করতে হয়। এটি বৈধ নকশা, কিন্তু এর মানে হলো বাদ পড়া একটি লাইন সার্ভারের প্রত্যাখ্যানের মতোই দেখায়।

পুনরায় সংযোগ দিন এবং ডিভাইসে যাচাই করুন

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

গন্তব্য নাম দিয়ে নয়, ঠিকানা দিয়ে পরীক্ষা করুন। একটি পরিচিত সার্ভিস পোর্টে TCP চেক ping-এর চেয়ে বেশি তথ্য দেয়, কারণ অনেক হোস্ট ICMP-এর উত্তর দেয় যদিও সার্ভিস পোর্ট ফিল্টার করা। ঠিকানা উত্তর দিলে কিন্তু নাম না দিলে আপনার প্রশ্নটি রিজলভার সংক্রান্ত, রাউটিং সংক্রান্ত নয়, এবং পরের অংশটি আপনার জন্য নয়।

এখানে দুটি স্কোপ চেকও প্রযোজ্য। Per-app VPN মানে হলো অ্যাড্রেস রুট থাকতে পারে অথচ আপনি যে অ্যাপ দিয়ে পরীক্ষা করছেন সেটি অন্তর্ভুক্ত সেটের বাইরে, তাই এমন অ্যাপ দিয়ে পরীক্ষা করুন যা সত্যিই ভেতরে আছে। আর একটি IPv4 প্রিফিক্স IPv6 পথ সম্পর্কে কিছুই বলে না; সার্ভিসটি dual-stack হলে সংশ্লিষ্ট IPv6 রুট যোগ করুন, নয়তো ক্লায়েন্ট আপনার অনভিপ্রেত পথ পছন্দ করবে বলে ধরে নিন।

একটি নেতিবাচক ফল আগেই চেনা ভালো: যদি full-tunnel রুট ইতিমধ্যে 0.0.0.0/0 কভার করে, তবে প্রিফিক্সটি অনুপস্থিত নয় এবং আবার যোগ করলে কিছুই বদলায় না। দ্বৈত কভারেজ সার্ভার-সাইড প্রত্যাখ্যান বা অনুপস্থিত উত্তর মেরামত করে না।

সার্ভারে পথটি শেষ করুন

ফোনের বাইরে তিনটি বিষয় সত্য হতে হবে। গেটওয়ের গন্তব্যে একটি রুট দরকার এবং ফোনের সোর্স সেদিকে ফরওয়ার্ড করার অনুমতি দরকার। টার্গেটকে সেই সোর্স গ্রহণ করে গেটওয়ে দিয়ে উত্তর ফেরত দিতে হবে, নয়তো নকশায় egress-এ সচেতন ট্রান্সলেশন দরকার। OpenVPN ম্যানুয়ালের route অপশন ক্লায়েন্ট-সাইড নির্দেশনা কভার করে; ফরওয়ার্ডিং ও রিটার্ন রাউটিং আলাদা মেশিনে আলাদা সেটিংস।

গন্তব্যটি গেটওয়ের ঠিক পেছনে নয় বরং অন্য একটি VPN ক্লায়েন্টের পেছনে থাকলে সার্ভারের সেই পিয়ারের সাবনেটের জন্য iroute দরকার। ওই নির্দেশনা সার্ভারের মালিকানাধীন এবং বলে কোন ক্লায়েন্ট একটি প্রিফিক্সের মালিক; একটি ফোন তার নিজের প্রোফাইল থেকে তা দিতে পারে না, এবং ক্লায়েন্ট-সাইড সম্পাদনা যতই হোক তার বিকল্প নয়।

রিটার্ন পথ স্পষ্টভাবে পরীক্ষা করুন। টানেলের বদলে ডিফল্ট রুটে যে উত্তর বেরিয়ে যায় তা ক্লাসিক half-open লক্ষণ তৈরি করে: সংযোগ এক দিকে প্রতিষ্ঠিত হয় আর কিছুই ফেরত আসে না। টার্গেট ফেরত রুট করতে না পারলে গেটওয়েতে সোর্স ট্রান্সলেশন বৈধ সমাধান, তবে এটি নিজস্ব পরিণতিসহ একটি নীতি সিদ্ধান্ত।

রোলব্যাক ও গ্রহণ

সম্পাদনার আগে আগের প্রোফাইলটি রেখে দিন। পরিবর্তন পরিস্থিতি খারাপ করলে একই পুনরায় আমদানি পথে সেই কপি ফিরিয়ে আনুন, আবার সংযোগ দিন, এবং পুরনো আচরণ ফিরে এসেছে নিশ্চিত করুন — তাতেই বোঝা যায় আপনি যা ভেবেছিলেন বদলেছেন সেটিই বদলেছে। যে রোলব্যাক পুরনো অবস্থা ফেরায় না তার মানে অ্যাপের কাছে তৃতীয় একটি কপি আছে যা আপনি খুঁজে পাননি।

চারটি শর্ত পূরণ হলে পরিবর্তনটি গ্রহণ করুন, নতুন সংযোগের পর এই ক্রমে পরীক্ষা করে: গন্তব্য তার সার্ভিস পোর্টে উত্তর দেয়, প্রত্যাশিত হলে ব্যক্তিগত নামটি রিজলভ হয়, HTTPS এখনও কাঙ্ক্ষিত হোস্টনেম যাচাই করে, এবং রিবুট বা Wi-Fi থেকে সেলুলারে বদলের পরেও সবকিছু কাজ করে। শেষ পরীক্ষাটিই এমন রুট ধরে যা Android টানেল পুনঃপ্রতিষ্ঠা করার আগ পর্যন্তই থাকে।

  • সম্পাদনার আগে নেটওয়ার্কের মালিক গন্তব্যটি অনুমোদন করেন কি না নিশ্চিত করুন।
  • ক্লায়েন্ট যে প্রোফাইল লোড করে সেখানে রুটটি রাখুন, তারপর পুনরায় আমদানি করে সংযোগ দিন।
  • সঠিক অ্যাড্রেস ফ্যামিলির জন্য, per-app স্কোপের ভেতরে, সার্ভিস পোর্ট দিয়ে যাচাই করুন।
  • ফরওয়ার্ডিং, রিটার্ন রাউটিং আর iroute সার্ভারে ঠিক করুন, ফোনে নয়।
  • রোলব্যাক কপি রাখুন, এবং রিবুটের পর আবার পরীক্ষা করুন।

সম্পর্কিত নিবন্ধ