কেন OpenConnect পৃষ্ঠাগুলি টানেলের MTU না কমানো পর্যন্ত আটকে থাকে

লগইন সফল হয়, পোর্টালের সামনের পৃষ্ঠা আঁকা হয়, তারপর একটি ড্যাশবোর্ড উইজেট বা একটি রিপোর্ট waiting for host-এ পড়ে থাকে যতক্ষণ না ব্রাউজার হাল ছেড়ে দেয়। পাবলিক সাইটগুলি সারা সময় স্বাভাবিকভাবে লোড হয়, এবং কোনো ক্রেডেনশিয়াল বদলায়নি। বড় উত্তর আটকে থাকার সময় ছোট উত্তর আসা প্যাকেট-আকারের সীমার লক্ষণ, অ্যাক্সেস নিয়মের নয়। প্রোফাইলে আর কিছু সম্পাদনা করার আগে এই পাঠটি নিশ্চিত করুন।

আকারের সমস্যাকে নীতি-সমস্যা থেকে আলাদা করুন

প্রত্যাখ্যান বাদ দিয়ে শুরু করুন। গেটওয়ে যদি আপনাকে প্রত্যাখ্যান করত, সংযোগটি পৃষ্ঠা অর্ধেক লোড করার বদলে সঙ্গে সঙ্গে ব্যর্থ হত। যে টানেল ওঠে কিন্তু কেবল বড় স্থানান্তরে আটকে যায়, সেটি আপনাকে বলে বাইরের পথ ভেতরের প্যাকেট বহন করতে পারছে না।

প্রক্রিয়াটি এনক্যাপসুলেশন। প্রতিটি ভেতরের প্যাকেট টানেল হেডার পায়, তাই যে পেলোড ভৌত লিঙ্কে ফিট করে সেটি এমন বাইরের প্যাকেট হয়ে যায় যা আর ফিট করে না, এবং do-not-fragment বিট বহনকারী যেকোনো কিছু ব্রাউজার বুঝতে পারে এমন উত্তর ছাড়াই ফেলে দেওয়া হয়।

do-not-fragment প্রোব দিয়ে সীমা মাপুন

অনুমান না করে সীমাটি মাপুন। এমন প্রোব পাঠান যা ফ্র্যাগমেন্টেশন প্রত্যাখ্যান করে এবং উত্তর ফিরে আসা পর্যন্ত পেলোড ধাপে ধাপে কমান, যেমন ping -M do -s 1472 host এর মতো একটি কমান্ড দিয়ে শুরু করুন। DF সেট থাকা অবস্থায় ফ্র্যাগমেন্টেশন দরকার বলে উত্তর অভিযোগ করলে বোঝায় মানটি এখনও বেশি। 1462-এ, তারপর 1452-এ পুনরাবৃত্তি করুন, এবং যে প্রথম আকারে উত্তর আসে সেখানেই থামুন। সংখ্যাটি যে হোস্টে প্রোব করেছেন তার সঙ্গে লিখে রাখুন, কারণ উত্তরটি ওই পথের, সাধারণভাবে প্রোটোকলের নয়।

টানেল যে ঠিকানায় সত্যিই ট্রাফিক পাঠায় সেটি প্রোব করুন। গেটওয়ের পাবলিক নামের বিরুদ্ধে বাইরের প্রোব এবং অভ্যন্তরীণ সার্ভারের বিরুদ্ধে ভেতরের প্রোব ভিন্ন হপ মাপে, এবং যেকোনো একটিতে ICMP ফিল্টারিং একটি সুস্থ পথকে ভাঙা দেখাতে পারে।

মানটি টানেল ডিভাইসে প্রয়োগ করুন

ফলাফলটি ক্লায়েন্ট যে ইন্টারফেস তৈরি করেছে সেটিতে প্রয়োগ করুন, Wi-Fi অ্যাডাপ্টারে নয়। লিনাক্স ক্লায়েন্টে সেটি ip link set dev tun0 mtu 1300 এবং তারপর ip link show tun0 — মানটি গৃহীত হয়েছে নিশ্চিত করতে। ক্লায়েন্ট যে ডিভাইসের নাম জানায় সেটিই ব্যবহার করুন, কারণ এটি বাস্তবায়নভেদে এবং টানেল কীভাবে তৈরি হয়েছে তার ওপর নির্ভর করে বদলায়।

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

আগে ক্লায়েন্টের নিজের MTU অনুরোধ ব্যবহার করুন

যখন আপনি আহ্বানটি নিয়ন্ত্রণ করেন, ক্লায়েন্ট পরে প্যাচ হওয়ার বদলে একটি আকার চাইতে পারে। --mtu সার্ভারের কাছে টানেল MTU চায়, এবং --base-mtu অন্তর্নিহিত পথের MTU ঘোষণা করে যাতে গেটওয়ে টানেলের সংখ্যাটি বের করতে পারে। দুটোই অনুরোধ, এবং ক্লায়েন্টের ম্যানুয়াল কোনোটিই গেটওয়ে মানবে বলে প্রতিশ্রুতি দেয় না।

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

যে স্থানান্তরটি ব্যর্থ হয়েছিল তা দিয়ে যাচাই করুন, তারপর এটি স্থায়ী করুন

স্থানীয় ip link পরিবর্তন ক্লায়েন্ট টানেলটি নতুন করে বানানো পর্যন্ত টেকে, যা পরের পুনঃসংযোগ বা পুনরারম্ভে ঘটে। মানটি যেখানে সংযোগ শুরু হয় সেখানে রাখুন: একটি র্যাপার যা ক্লায়েন্ট চালিয়ে তারপর ডিভাইসটি সমন্বয় করে, ExecStartPost ধাপসহ একটি systemd ইউনিট, বা গেটওয়ে মেনে নিলে ক্লায়েন্ট অপশন। প্রোফাইলের পাশে ভার্সন নিয়ন্ত্রণে রাখুন যাতে পরের ব্যক্তি দেখতে পারে সংখ্যাটি কেন সেখানে।

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

একই স্থানান্তর যদি একই বিন্দুতে আটকে থাকে, তাহলে MTU তত্ত্বটি অপ্রমাণিত। টানেলে ট্রাফিক ধরে নিন এবং সংখ্যাটি আবার বদলানোর আগে দেখুন কোন পক্ষ পাঠানো থামায়, আর আগের মানটি লিখিত রাখুন যাতে রোলব্যাক এক কমান্ডেই থাকে।