পৃষ্ঠাগুলি লোড হয় কিন্তু VPN-এ আপলোড আটকে যায়: কোন কারণটি জেতে
আকার-নির্ভর আটকে যাওয়া পাথ MTU ত্রুটির সঙ্গে মেলে, আবার DNS, অ্যাপ্লিকেশন সীমা বা দোলায়মান টানেলের সঙ্গেও মেলে। কোনটি, তা চারটি পর্যবেক্ষণ ঠিক করে।
পৃষ্ঠাগুলি লোড হয়, VPN সংযুক্ত বলে জানায়, আর ফাইল আপলোড প্রতিবার একই জায়গায় থেমে যায়। এই বর্ণনার সঙ্গে চারটি ব্যাখ্যা মেলে: প্যাকেট-আকারের সমস্যা, নাম-সমাধানের সমস্যা, অ্যাপ্লিকেশন সীমা এবং বারবার রিসেট হওয়া একটি টানেল। প্রতিটিকে আলাদা পর্যবেক্ষণ দিয়ে সত্য বা মিথ্যা প্রমাণ করা যায়, তাই সিদ্ধান্তটি কারণ অনুমান করার বদলে সঠিক পরীক্ষা বেছে নেওয়ার বিষয়।
চার প্রার্থী আর একটি আকৃতি
ব্যর্থতার আকৃতি দিয়ে শুরু করুন, কারণ কোনো যন্ত্র খোলার আগেই এটি তালিকার বেশিরভাগ বাদ দেয়। নির্দিষ্ট আকারে ঘটে যাওয়া আটকে যাওয়া বিপরীত প্রমাণ না হওয়া পর্যন্ত একটি আকারের সমস্যা। এলোমেলো জায়গায় ঘটে যাওয়া আটকে যাওয়া ক্ষতি বা স্থিতিশীলতার সমস্যা। সংযোগ খোলার আগে ব্যর্থতা একটি নামের সমস্যা।
চতুর্থ প্রার্থী হলো অ্যাপ্লিকেশন। আপলোড সীমা, অনুরোধের সময়সীমা এবং প্রক্সির বডি-আকারের সীমা এমন ব্যর্থতা তৈরি করে যা ব্রাউজার থেকে নেটওয়ার্ক ত্রুটির মতো দেখায়, এবং সেগুলি সাধারণত আটকে যাওয়ার বদলে প্রত্যাখ্যান হিসেবে আসে।
কিছু পরীক্ষা করার আগে পর্যবেক্ষিত আকৃতিটি লিখে রাখুন। "প্রায় একই বাইট সংখ্যায়, প্রতিবার, টানেল চালু থাকা অবস্থায় থেমে যায়" — "আপলোড কাজ করে না"-এর চেয়ে অনেক শক্তিশালী সূচনা বিন্দু।
তারপর পরীক্ষার সময় পাথ স্থির রাখুন। প্রস্থান, প্রোটোকল ও সার্ভার একসঙ্গে বদলালে এমন ফল আসে যা আপনি কোনোটির প্রতি আরোপ করতে পারেন না। প্রতি চালনায় একটি চলক, এবং সেটি লিখে রাখুন।
নীতি স্পর্শ করার আগে আকার ভাগ করুন
সবচেয়ে সস্তা পার্থক্যকারী হলো এমন একটি প্রোব যা একটি সংখ্যা বদলায়। গন্তব্যে ক্রমবর্ধমান আকারের, ফ্র্যাগমেন্টেশন-নিষিদ্ধ পিং পাঠান, এবং আপনি যে ফাইল নিয়ন্ত্রণ করেন তা একই পরিষেবায় আপলোড করুন, তারপর দুটির প্রতিটি কোথায় থামে তা তুলনা করুন।
ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/uploadপ্রথম কমান্ডটি জানায় পূর্ণ-আকারের প্যাকেট আদৌ পাথ পেরোয় কি না। 1500 বাইটের MTU-তে যে ICMP পেলোড ফ্র্যাগমেন্ট হয় না তার সর্বোচ্চ আকার 1472 বাইট, এবং ভেতরের প্যাকেট শুরুর আগেই টানেল সেই বাজেট থেকে আরও নিয়ে নেয়। দ্বিতীয়টি অ্যাপ্লিকেশন-স্তরের স্থানান্তরের জন্য একটি আকার ও একটি সময় দেয়, আর সেটিই আসলে গুরুত্বপূর্ণ সংখ্যা।
| Candidate | Observation that confirms it | Observation that rules it out |
|---|---|---|
| Path MTU or blocked ICMP feedback | Stall at a consistent size; large do-not-fragment probes fail | Small and large transfers both complete |
| Name resolution | The connection never opens for that name | The connection opens and then stalls mid-transfer |
| Application or proxy limit | A clean rejection at a documented size | No log entry on the server at all |
| Tunnel instability | Reconnects or rekeying during the transfer | The tunnel uptime is unchanged across the failure |
দুটিকে একসঙ্গে পড়ুন। একটি থ্রেশহোল্ডের উপরে ব্যর্থ হওয়া প্রোব আর একই থ্রেশহোল্ডের কাছে থেমে যাওয়া আপলোড — এটি সুসংগত গল্প। সব প্রোব সফল হওয়া সত্ত্বেও আপলোড এমন বাইট সংখ্যায় আটকে থাকলে যা পাথ স্পষ্টতই বহন করে, তা অ্যাপ্লিকেশন বা সার্ভারের দিকে ইঙ্গিত করে, এবং MTU-র যত কাজই করুন তা বদলাবে না। সেই নেতিবাচক ফলটি ইতিবাচক ফলের সমান মূল্যবান। এটি তদন্তের সবচেয়ে ব্যয়বহুল শাখাটি সরিয়ে দেয়।
তারপর স্থানান্তরের সময় স্থিতিশীলতা যাচাই করুন, কারণ বড় আপলোডের মাঝখানে কী পুনঃনির্ধারণ করা একটি টানেল এমন ব্যর্থতা তৈরি করে যা আকার-নির্ভর মনে হয়, কিন্তু নয়। আপটাইম পাঠই তা নিশ্চিত করার সবচেয়ে সস্তা উপায়।
মেরামত ও বিকল্প সমাধানের মধ্যে সিদ্ধান্ত নিন
প্রমাণ যদি আকারের দিকে ইঙ্গিত করে, তবে দুটি সৎ উত্তর আর একটি অসৎ উত্তর আছে। সৎ দুটি হলো প্রয়োজনীয় ICMP প্রতিক্রিয়া অনুমোদন করে পাথ-MTU আবিষ্কার পুনরুদ্ধার করা, অথবা ঘোষিত সেগমেন্ট আকার আটকে রাখা যাতে সহকর্মীরা ছোট সেগমেন্ট পাঠায়। অসৎটি হলো কোনো ফোরাম থেকে নকল করা মানে ইন্টারফেস MTU কমানো আর তা কী বদলেছে তা কখনও যাচাই না করা।
পছন্দ নির্ভর করে আপনি কী নিয়ন্ত্রণ করেন তার উপর। আপনি যে নেটওয়ার্ক চালান, সেখানে ICMP বার্তাগুলি অনুমোদন করাই পরিচ্ছন্ন সমাধান, কারণ এটি প্রতিটি প্রোটোকলের জন্য কৌশলটি চালু রাখে। যে পাথে আপনি নিয়ন্ত্রণ করেন না, সেখানে ক্ল্যাম্পিংই বাস্তব বিকল্প, এবং তা সার্ভারজুড়ে নয়, সংকীর্ণভাবে প্রয়োগ করা উচিত।
প্রমাণ যদি অ্যাপ্লিকেশনের দিকে ইঙ্গিত করে, তবে অ্যাপ্লিকেশন বা তার প্রক্সি কনফিগারেশন সারান। 413 প্রতিক্রিয়া আর ঝুলে থাকা সংযোগ ভিন্ন ব্যর্থতা, এবং দ্বিতীয়টি সাধারণত নিজস্ব সীমাসহ প্রক্সি থাকা একটি শৃঙ্খলে কোথাও একটি সময়সীমা।
যেভাবেই হোক, মূল মানগুলি রেখে দিন এবং ফিরিয়ে আনার পরে আবার পরীক্ষা করুন। যে পরিবর্তন একটি সফল স্থানান্তরের সঙ্গে মিলে যায় তা প্রমাণ নয় যে পরিবর্তনটিই তা ঘটিয়েছে, আর ফিরিয়ে আনার ক্ষমতাই রোগনির্ণয়কে কাকতালীয়তা থেকে আলাদা করে।
সিদ্ধান্তটি লিখে রাখুন যাতে পরের ঘটনাটি পর্যন্ত টেকে
চারটি তথ্যই যথেষ্ট: পর্যবেক্ষিত ব্যর্থতার আকৃতি, প্রোবের ফলাফল, আপনি যে পরিবর্তন করেছেন এবং পুনঃপরীক্ষার ফলাফল। এগুলি দিয়ে পরের ব্যক্তি বলতে পারবেন সমস্যাটি একই, নাকি একই উপসর্গ পরা নতুন একটি সমস্যা।
পাথের প্রসঙ্গও টুকে রাখুন, কারণ MTU-সংক্রান্ত অনুসন্ধান একটি নির্দিষ্ট লিঙ্কের জন্য প্রযোজ্য। বাড়িতে কাজ করে হোটেলে ব্যর্থ হওয়া ল্যাপটপের দুটি পাথ থাকে, আর একটিতে প্রয়োগ করা সমাধান অন্যটি সম্পর্কে কিছুই বলে না।
শেষে, "VPN আপলোড ভেঙে দিয়েছে" এই সারাংশের বিরুদ্ধে দাঁড়ান। টানেলটি কাজ করা ও ব্যর্থ উভয় ক্ষেত্রেই উপস্থিত ছিল; যা বদলেছিল তা হলো পাথকে যে প্যাকেট বহন করতে হতো তার আকার, বা স্থানান্তরটি যেখানে থামানো হয়েছিল। প্রকৃত কৌশলের নাম দেওয়াই টিপ্পনীটিকে কাজে লাগায়।