Ping কোনো প্রমাণ নয়: দুই সাইটের মধ্যের পথ পরীক্ষা করুন

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

যে ক্লায়েন্টের সেবা দরকার সেখান থেকেই শুরু করুন

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

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

প্রতিটি প্রান্তে পথ হাঁটুন

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

ip route get 10.10.0.5
sudo tcpdump -ni any host 10.10.0.5 and port 445
sudo tcpdump -ni any net 10.10.0.0/24 and net 10.20.0.0/24

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

অ্যাপ্লিকেশন যে প্রোটোকল ব্যবহার করে তা-ই ব্যবহার করুন

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

nc -vz 10.10.0.5 445
curl -sv --max-time 5 https://files.corp.internal/ -o /dev/null
openssl s_client -connect 10.10.0.5:443 -servername files.corp.internal

সম্পূর্ণ TCP হ্যান্ডশেক ওই পোর্টের জন্য পৌঁছানোযোগ্যতা ও নীতি প্রমাণ করে। এটি প্রমাণ করে না যে অ্যাপ্লিকেশন কাজ করছে: প্রমাণীকরণ, আপলোড বা নির্দিষ্ট API কল এখনো ব্যর্থ হতে পারে। ব্যবহারকারীরা যে কাজটি সত্যিই করেন তা পরীক্ষা করুন, বারবার প্রকৃত লেনদেন জমা না দিয়ে নিরীহ সমতুল্য কিছু দিয়ে।

যে অবস্থায় ব্যর্থ হয় তা পুনরুৎপাদন করুন

যে ব্যর্থতা কেবল বড় স্থানান্তরে দেখা যায় তা আকারের সমস্যা, সংযোগের সমস্যা নয়। don't-fragment বিট বসিয়ে বড় প্যাকেট পাঠান এবং কোথায় থামে দেখুন। ছোট অনুরোধ সফল হয় আর বড়টি আটকে গেলে টানেলের MTU এবং গেটওয়েতে MSS পরিচালনা পরবর্তী সন্দেহভাজন।

ping -M do -s 1400 10.10.0.5
ping -M do -s 1472 10.10.0.5
curl -sS --max-time 30 -F file=@./sample.bin https://files.corp.internal/upload

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

সমাধানের পরে একই পরীক্ষা আবার করুন

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

চারটি ভিত্তি মান ও ফলাফল লিখে রাখুন। একই উপসর্গের পরবর্তী প্রতিবেদন তখন পিং নয়, প্রমাণ থেকে শুরু করতে পারবে।