VPN-এ ping কাজ করে কিন্তু সাইট আটকে যায়: আকার দেখুন

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

সবচেয়ে ছোট প্রশ্ন থেকে সবচেয়ে বড় প্রশ্নের দিকে এগিয়ে যান, এবং প্রতিটি ধাপ আসলে কী প্রমাণ করেছে তা লিখে রাখুন।

প্রত্যুত্তর অনেক ছোট প্রশ্নের উত্তর দেয়

একটি প্রত্যুত্তর বলে যে গন্তব্যের IP স্ট্যাক আপনার উৎসের ICMP অনুরোধের উত্তর দিয়েছে। আপনি যে পোর্টে TCP শ্রবণকারী আছে কি না, কোনো নীতি সেই পোর্টকে অনুমতি দেয় কি না, বা গন্তব্য হোস্ট গেটওয়ে থেকে স্বাধীনভাবে ট্রাফিক ফিল্টার করে কি না — এসবের কিছুই এটি বলে না। যে গেটওয়ে একটি পরিষেবাকে অনুমতি দেয়, সে অন্য একটি পরিষেবাকে ফেলে দিতে পারে, যদিও দুই লক্ষ্যই ping-এ উত্তর দেয়। উত্তরটিকে একটি প্যাকেট ও একটি দিক সম্পর্কে একটি মাত্র তথ্য হিসেবে পড়ুন।

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

সংযোগ শুরু হয়েছে কি না তা খুঁজে বের করুন

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

curl -v --max-time 10 https://internal.example/ -o /dev/null
ss -tn state established '( dport = :443 )'

MTU সেটিংসে হাত দেওয়ার আগে এই তিনটির মধ্যে কোনটি আপনি দেখেছেন তা লিখে রাখুন। প্রত্যাখ্যাত সংযোগ ঠিক করতে টানেলের আকার বদলানো সেই পরিবর্তনকে অপচয় করে এবং কিছু সময়ের জন্য আসল কারণ লুকিয়ে রাখে।

নির্দিষ্ট সংখ্যা দিয়ে আকার মাপুন

ভার তৈরি হলে যখন আটকে যায়, তখন ফ্র্যাগমেন্ট নিষিদ্ধ বিট সেট করে একটি প্যাকেট আকার পরীক্ষা করুন এবং হিসাবটি উল্লেখ করুন যাতে ফলাফলের অর্থ থাকে। iputils সহ Linux-এ 1392 বাইটের পেলোডের সঙ্গে 8 বাইটের ICMP হেডার এবং 20 বাইটের IPv4 হেডার যোগ করলে ভিতরের প্যাকেট ঠিক 1420 বাইট হয়। টিকিটে সেই হিসাব লিখুন, কারণ গেটওয়েতে পৌঁছানো খালি ping কোনো অ্যাপ্লিকেশন সম্পর্কে কিছুই প্রমাণ করে না।

ping -4 -M do -s 1392 10.44.0.10
ping -4 -M do -s 1372 10.44.0.10

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

বাইরের পথ হিসাব করুন

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

IPv4-তে পথ MTU আবিষ্কার নির্ভর করে এমন প্যাকেট সম্পর্কে প্রতিক্রিয়ার উপর যেগুলো ফ্র্যাগমেন্টেশন ছাড়া পাঠানো যায় না, আর IPv6 ব্যবহার করে Packet Too Big বার্তা। IPv4 স্পেসিফিকেশন সেই প্রক্রিয়া বর্ণনা করে। প্রতিক্রিয়া ফিল্টার করলে প্রেরকের শেখার ক্ষমতা ভেঙে যায়, ফলে সে এমন প্যাকেট বারবার পাঠাতে থাকে যা কখনোই ফিট হবে না। এজন্যই কাজ করা ছোট অনুরোধ আর ব্যর্থ বড় অনুরোধ এত সহজে সহাবস্থান করে।

একটি সংখ্যা বদলান এবং অ্যাপ্লিকেশন আবার পরীক্ষা করুন

টানেলের MTU কমান, অথবা TCP-র জন্য সর্বোচ্চ সেগমেন্ট আকার সীমিত করুন, তারপর প্রোবের বদলে মূল অ্যাপ্লিকেশন পরীক্ষাটি পুনরাবৃত্তি করুন। পরিবর্তনের পরে সফল হওয়া প্রোব আর এখনও আটকে থাকা অ্যাপ্লিকেশন একই রকম আকারের ভিন্ন সমস্যা, এবং কেবল অ্যাপ্লিকেশন পরীক্ষাই তাদের আলাদা করে।

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

আপনি যে প্রতিটি আকারে চেষ্টা করেছেন তাতে অ্যাপ্লিকেশন কাজ করলে, সংখ্যা সমন্বয় করা বন্ধ করুন এবং যে নীতি কাজ করা পরিষেবাকে ব্যর্থ পরিষেবা থেকে আলাদা করে সেটি দেখুন।