DNS ব্যর্থতা নাকি MTU সমস্যা? অনুরোধটি আসলে কোথায় থামে

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

দুটি ভিন্ন স্তরে দুটি ব্যর্থতা

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

লক্ষণগুলি এমনভাবে ভিন্ন যে কোনো টুল ছাড়াই তা লক্ষ্য করা যায়। DNS ব্যর্থতা তাৎক্ষণিক ও ধারাবাহিক: ব্রাউজার বলে সার্ভারটি পাওয়া যাচ্ছে না। MTU ব্যর্থতা আংশিক: পৃষ্ঠা শুরু হয়, কিছু রিসোর্স আসে, আর একটি বড় প্রতিক্রিয়া বা আপলোড আটকে যায়।

আপনার লক্ষণ যদি আংশিক হয়, তবে DNS দেখা বন্ধ করুন।

ধাপ 1: নামটি আদৌ রিজলভ হয় কিনা

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

অপারেটিং সিস্টেম যে রিজলভার ব্যবহার করত, সেটিকে জিজ্ঞাসা করুন, তারপর তুলনা করুন:

dig +short vpn.example.com
dig +short vpn.example.com @10.0.0.53

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

ধাপ 2: ট্রান্সফার কোথায় থামে

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

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

একটি পুনরাবৃত্তিযোগ্য আটকে যাওয়া দশটি বিচ্ছিন্ন ঘটনার চেয়ে বেশি মূল্যবান।

হ্যান্ডশেকের পরেই MTU কেন ক্ষতি করে

TCP হ্যান্ডশেক ছোট প্যাকেট ব্যবহার করে, তাই যে পথ পূর্ণ আকারের সেগমেন্ট বহন করতে পারে না সেখানেও তা সফল হয়। ব্যর্থতা দেখা দেয় যখন প্রেরক ফ্র্যাগমেন্টেশন-নিষেধ বিট দিয়ে বড় প্যাকেট পাঠায়, একটি লিঙ্ক তা ফেলে দেয়, আর সীমা জানানোর কথা থাকা ICMP বার্তাটি কখনো পৌঁছায় না কারণ একটি ফিল্টার তা খেয়ে ফেলেছে। এরপর প্রেরক একই আকারে আবার চেষ্টা করে এবং ট্রান্সফার আটকে যায়।

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

অনুমান না করে আকারটি স্পষ্টভাবে মাপুন:

ping -M do -s 1472 203.0.113.20
tracepath 203.0.113.20

একটি স্তর বদলুন, তারপর প্রমাণ করুন

নামের জন্য রিজলভার নীতি বদলে একই লুকআপ আবার চালান। আকারের জন্য MTU পদ্ধতি ব্যবহার করুন, মূল মানগুলি লিখে রেখে এবং ফিরিয়ে নেয়ার প্রস্তুতি নিয়ে, কারণ টানেলের প্রকৃত MTU না জেনে MSS কমিয়ে আনা এক আটকে যাওয়াকে আরকটির সঙ্গে বদলায়।

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

এই রেকর্ডটিই DNS, প্যাকেটের আকার এবং প্রমাণীকরণকে এমন একগুছ্ছ স্থায়ী বিকল্প পথে পরিণত হওয়া থেকে আটকায় যা কেউ ব্যাখ্যা করতে পারে না। কাঁচা IP দিয়ে পরীক্ষা করা এমন একটি শর্টকাটের ভালো উদাহরণ যা TLS পরিচয় বদলে দয়, আর তুলনা সফল করতে সার্টিফিকেট যাচাই বন্ধ করা কোনো রোগনির্ণয় নয়।