iPhone VPN MTU: নম্বর বদলানোর আগে মালিক কে তা ঠিক করুন
তিনটি প্রশ্ন ঠিক করে দেয় অ্যাপ, গেটওয়ে প্রোফাইল বা ফোনের কেউই কি আকার বদলাতে পারে। Mac থেকে নম্বর ধার করার আগে সেগুলোর উত্তর দিন।
iPhone VPN প্যাকেট আকার নিয়ে প্রতিটি আলোচনা শেষে ppp0 নামের একটি ইন্টারফেসের বিরুদ্ধে একই Mac কমান্ডের প্রস্তাব দেয়, সাধারণত সঙ্গে একটি নম্বর থাকে। এটি এখানে প্রযোজ্য নয়, এবং ওই ইন্টারফেস সংশ্লিষ্ট সংযোগের না হলে Mac-এও এটি সঠিক নিয়ন্ত্রণ হতো না। ফোনে নম্বরটির মালিক যে টানেলটি বাস্তবায়ন করে: নেটিভ প্রোফাইলের জন্য অপারেটিং সিস্টেম, অ্যাপের জন্য প্যাকেট-টানেল প্রদানকারী, বা নথিভুক্ত অ্যাট্রিবিউট নিয়ে দর-কষাকষি হলে গেটওয়ে। এই তিনটির মধ্যে কোনটির সঙ্গে আপনার কাজ, তা তিনটি প্রশ্নেই ঠিক হয়।
প্রশ্ন এক: কোন ক্লায়েন্ট চলছে
একটি নেটিভ IKEv2 প্রোফাইল, অন্তর্নির্মিত Cisco IPsec প্রোফাইল এবং তৃতীয় পক্ষের Cisco ক্লায়েন্ট—এই তিনটি ভিন্ন বাস্তবায়ন, সমর্থিত অ্যাট্রিবিউটের তিনটি ভিন্ন সেট নিয়ে। সেটিংসে থাকা প্রোফাইল ধরন বলে দেয় ফোনটি আসলে কোনটি চালু করেছে, আর অ্যাপ তালিকা বলে পথে আদৌ কোনো প্রদানকারী আছে কি না। সেখান থেকেই শুরু করুন, কারণ বাকি সিদ্ধান্ত এরপরেই আসে। অ্যাপ তালিকায় কোনো প্রদানকারী না দেখালে টানেলের মালিক অপারেটিং সিস্টেম।
গেটওয়ে বিক্রেতা থেকে বাস্তবায়ন অনুমান করবেন না। একটি Cisco হেডএন্ড এমন ক্লায়েন্টের সংযোগও শেষ করতে পারে যারা বিক্রেতার নাম ছাড়া কিছুই ভাগ করে না। পুরোনো রিলিজে পুরোনো বিল্ডের স্ক্রিনশট বলে দেয় ওই জুটি কী সমর্থন করত, আপনার হাতের ফোনটি কী করে তা নয়।
প্রশ্ন দুই: মানটির মালিক কে
Apple নেটওয়ার্ক এক্সটেনশন সেটিংস অবজেক্টের মাধ্যমে প্যাকেট-টানেল ডেভেলপারদের কাছে MTU প্রপার্টি প্রকাশ করে। এটি এমন প্রদানকারীর জন্য API যে নিজের টানেল কনফিগার করে, এমন সুইচ নয় যা ব্যবহারকারী বা প্রশাসক অন্য কারও ইনস্টল করা ক্লায়েন্টে চালু করতে পারেন। তৃতীয় পক্ষের অ্যাপ এটি প্রকাশ করা, উপেক্ষা করা বা মান হার্ড-কোড করা বেছে নিতে পারে।
নেটিভ প্রোফাইলে ইন্টারফেসের আকার অপারেটিং সিস্টেম বেছে নেয়, আর ফোনে এর জন্য কোনো এডিটর নেই। Cisco রিমোট-অ্যাক্সেস গেটওয়ের জন্য সংযোগ প্রোফাইলের একটি নথিভুক্ত অ্যাট্রিবিউট আছে, এবং তা প্রযোজ্য হয় কি না তা নির্ভর করে ক্লায়েন্ট, রিলিজ ও দর-কষাকষিকৃত ট্রান্সপোর্টের উপর। নথিভুক্ত ও মানা—এই দুইয়ের ফাঁকেই কপি করা নম্বরটি ভুল হয়।
| Owner | Who can change it | Reachable from the phone |
|---|---|---|
| Packet-tunnel provider | The app vendor through its API | Only if the app exposes a setting |
| Native IKEv2 or Cisco IPsec profile | The operating system | No user control |
| Gateway group policy attribute | The gateway administrator | If the client honours it |
প্রশ্ন তিন: উপসর্গটি আদৌ আকার-নির্ভর কি
আকারের সমস্যার একটি স্বাক্ষর আছে: ছোট অনুরোধ সফল হয়, বড় আপলোড বা বড় প্রতিক্রিয়া আটকে যায়, আর একই সেবা অন্য অ্যাক্সেস নেটওয়ার্কে কাজ করে। ফিল্টারিং, অ্যাপের পেলোড সীমা এবং আটকে যাওয়া সার্ভারও একই ধরনের অভিযোগ তৈরি করতে পারে, তাই যে একটি অপারেশন ব্যর্থ হয় তার পাশে যে একটি কাজ করে তা লিখে রাখুন। অ্যাপ সময় ও আকার জানালে দুটোই তা সহ লিখুন। ওই জোড়া ছাড়া পরের প্রতিটি পরিবর্তনই অনুমান।
একই পরীক্ষা Wi-Fi এবং মোবাইল নেটওয়ার্কে চালান। যে ব্যর্থতা নেটওয়ার্ককে অনুসরণ করে তা পথের দিকে ইঙ্গিত করে; যে ডিভাইসকে অনুসরণ করে তা ক্লায়েন্ট বা প্রোফাইলের দিকে, আর দুটির আলাদা মালিক দরকার। দুই বারই একই সেবা ও একই অ্যাকাউন্ট ব্যবহার করুন, নইলে তুলনাটি কিছুই বলে না।
Mac-এর রেসিপিটি বারবার আসে কেন
PPP-ভিত্তিক ডেস্কটপ VPN-এর বছরের পর বছর ইন্টারফেসের আকার বদলানোকে বৈধ স্থানীয় উপায় বানিয়েছিল, আর সেই নির্দেশনা মোবাইল আলোচনায় কপি হয়ে গেছে। ফোনে কোনো শেল নেই, এমন ইন্টারফেস নাম নেই, আর পুনঃসংযোগের পর কোনো স্থায়িত্ব নেই। 2011 সালে ডেস্কটপ সমস্যার সমাধান করা একটি রেসিপি, তাকে সত্য করে তোলা শর্তগুলোর চেয়ে অনেক দূর এগিয়েছে। আলোচনা যা-ই দাবি করুক, মোবাইল ক্লায়েন্ট এতে কোনো শেল কমান্ড মানে না।
কপি করা মানটিকে সেটিং নয়, বরং পথ সম্পর্কে একটি অনুমান হিসেবে ধরুন। ছোট আকারে স্থানান্তর কাজ করলে আর বড় আকারে নির্ভরযোগ্যভাবে ব্যর্থ হলে, পথ সম্পর্কে আপনার প্রমাণ আছে; তবু তার উপর কাজ করার অনুমতি আছে এমন উপাদানটি আপনাকে খুঁজে বের করতে হবে। সেই খোঁজ সাধারণত গেটওয়ে প্রোফাইল বা অ্যাপ বিক্রেতার কাছে শেষ হয়, ফোনে খুব কমই।
ট্রান্সপোর্ট উত্তরটি বদলে দেয়
সেশনটি IPsec নয়, TLS দিয়ে চললে গেটওয়েতে TCP সেগমেন্টেশন সমন্বয় সাহায্য করতে পারে, কারণ এটি TCP প্রবাহের জন্য ঘোষিত সেগমেন্ট আকার নতুন করে লেখে। UDP ট্রাফিকের জন্য এটি কিছুই করে না, আর সেখানে আধুনিক ওয়েবের ভাগ মানুষ যতটা ভাবে তার চেয়ে বেশি। পরিবর্তনের প্রস্তাব দেওয়ার আগে দর-কষাকষিকৃত ট্রান্সপোর্ট দেখুন, আর টিকিটে লিখুন কোন ট্রান্সপোর্টে প্রভাব পড়বে বলে আপনি আশা করছেন।
পথ MTU ডিসকভারি আছে যাতে প্রান্তবিন্দু অনুমান না করে আসল সীমাটি জানতে পারে। প্রতিক্রিয়া আটকে ছোট আকার হার্ড-কোড করা মানে প্রতিটি সংযোগে স্থায়ী, লুকানো খরচের বিনিময়ে কাজ করা বড় স্থানান্তর হারানো।
গেটওয়ে দলকে কী জিজ্ঞাসা করবেন
তিনটি জিনিস চান: অ্যাট্রিবিউটের সঠিক নাম ও তার পরিধি, মোতায়েন করা ক্লায়েন্ট তা মানে কি না, এবং সেশন কোন ট্রান্সপোর্টে দর-কষাকষি করেছে। একটি গ্রুপ নীতিতে প্রয়োগ করা পরিবর্তন পরীক্ষাযোগ্য; বৈশ্বিক সম্পাদনা নয়, আর তা ঝুঁকি সরিয়ে দেয় এমন ব্যবহারকারীদের উপর যারা কখনো সমস্যা জানাননি। নথির রেফারেন্সও চান, কারণ রিলিজের মধ্যে অ্যাট্রিবিউটের নাম বদলায়।
তারপর একটি জিনিস বদলে মূল ব্যর্থ অপারেশনটি আবার পরীক্ষা করুন, স্পিড-টেস্ট ডাউনলোড নয়। ক্লায়েন্ট সংস্করণ ও অ্যাক্সেস নেটওয়ার্কসহ আগে-পরে রেকর্ড রাখুন, যাতে পরের প্রতিবেদন নতুন করে বিতর্ক না হয়ে তুলনা করা যায়।
মূল আকারেও অপারেশনটি ব্যর্থ হলে, আকারটি কারণ ছিল না। এই সিদ্ধান্তটিও লিখে রাখুন, যাতে পরের মানুষটি একই অনুমান আবার না খোলে।