Linux EHOSTUNREACH ও OpenVPN: কোন পরবর্তী হপ ব্যর্থ হলো?

EHOSTUNREACH যতটা দূরবর্তী ব্যর্থতা, ততটাই স্থানীয় সিদ্ধান্ত। কার্নেল একটি প্যাকেট প্রত্যাখ্যান করতে পারে কারণ কোনো রুট বলে গন্তব্য অগম্য, কারণ Ethernet পরবর্তী হপ কখনও উত্তর দেয়নি, অথবা কারণ পথের আরও দূর থেকে একটি ICMP host-unreachable প্রতিবেদন এসেছে। প্রতিটি উৎস আলাদা টেবিল বা ক্যাশে থাকে এবং প্রতিটি আলাদা জায়গায় ঠিক হয়। সাইফার স্পর্শ করার বা টানেল পুনরায় ইনস্টল করার আগে নির্বাচিত রুট ও পরবর্তী হপের অবস্থা পড়ুন।

ক্লায়েন্ট আসলে যে ঠিকানা ও নেমস্পেস ব্যবহার করে তা বেছে নিন

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

লুকআপটিকে ব্যর্থ অ্যাপ্লিকেশনের মতো একই সোর্স, মার্ক ও টেবিল প্রসঙ্গ ব্যবহার করতে হবে, নইলে এটি এমন প্রশ্নের উত্তর দিতে পারে যা কেউ করেনি। একটি উদাহরণমূলক IPv4 পিয়ারের জন্য কেবল-পঠন পরীক্ষাগুলো হলো:

ip -4 route get 198.51.100.25
ip -4 neigh show 198.51.100.1
ip -4 route show table all | grep -w unreachable

প্রশাসনিক শেল থেকে পাওয়া ফলাফল কেবল প্রমাণ করে সেই শেল কী করত। ক্লায়েন্ট যদি ফায়ারওয়াল মার্ক সেট করে বা VRF-এ বাঁধে, তবে মিলে যাওয়া মার্ক দিয়ে বা VRF-এর ভিতরে লুকআপটি পুনরাবৃত্তি করুন এবং নির্বাচিত রুট ও পরবর্তী হপ তুলনা করুন। নিশ্চিত করার প্রথম ঠিকানা হলো প্রোফাইলের পিয়ার ঠিকানা, ব্যবহারকারীর বলা ক্লাস্টার বা সেবা নয়।

একটি স্পষ্ট অগম্য রুট প্যাকেটটি স্থানীয়ভাবে প্রত্যাখ্যান করে

unreachable ধরনের রুট একটি ইচ্ছাকৃত স্থানীয় উত্তর. এটি কার্নেলকে প্যাকেটটি বাতিল করতে এবং প্রেরকের কাছে EHOSTUNREACH ফেরত দিতে বলে, তাই ত্রুটিটি তৎক্ষণাৎ এবং মেশিন থেকে কোনো ট্রাফিক না বেরিয়েই দেখা যায়। কেউ বা কোনো অটোমেশন ওই রুটটি সেখানে ইচ্ছাকৃতভাবে বসিয়েছে।

রুটের ধরনগুলো বিনিময়যোগ্য নয়। Blackhole প্রেরকের কাছে ত্রুটি না দিয়েই প্যাকেট বাতিল করে, prohibit EACCES ফেরত দেয়, আর unreachable EHOSTUNREACH ফেরত দেয়। তাই পুনঃসংযোগের সময় সিঙ্ক রুট ইনস্টল করা একটি VPN সহায়ক host-unreachable ত্রুটির ঝাঁক তৈরি করতে পারে যা টানেল ওঠার সাথে সাথে মিলিয়ে যায়, অথচ blackhole রুট বরং নীরব টাইমআউট তৈরি করত।

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

মৃত প্রতিবেশী Ethernet-এ একই ত্রুটি তৈরি করে

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

প্রতিবেশী টেবিলটি ধাপটির নাম দেয়। INCOMPLETE মানে সমাধান এখনও চলছে, FAILED মানে শেষ চেষ্টা কোনো উত্তর পায়নি, আর REACHABLE বা STALE মানে কার্নেলের একটি ব্যবহারযোগ্য ঠিকানা আছে। VPN গেটওয়ের জন্য FAILED এন্ট্রি একটি স্থানীয় ডেলিভারি সমস্যা, টানেলের দূর প্রান্ত সম্পর্কে প্রমাণ নয়।

প্রকৃত পরবর্তী হপের জন্য এন্ট্রিটি পড়ুন, দূরবর্তী ইন্টারনেট ঠিকানার জন্য নয়। দূরবর্তী ঠিকানায় সাধারণত রাউটারের মাধ্যমে পৌঁছানো হয়, তাই এর নিজস্ব ARP রেকর্ড থাকবে না; তার জন্য জিজ্ঞাসা করা একটি শ্রেণিগত ভুল যা মানুষকে এমন একটি অনুপস্থিত এন্ট্রি খুঁজতে পাঠায় যা কখনও থাকার কথা ছিল না।

দূরবর্তী প্রতিবেদন ও অ্যাসিঙ্ক্রোনাস UDP ত্রুটি

EHOSTUNREACH বাইরে থেকেও আসতে পারে। যে রাউটার প্যাকেটটি ফরওয়ার্ড করতে পারে না সে ICMP host unreachable পাঠাতে পারে, এবং কার্নেল সেই প্রতিবেদনটি প্রবাহের মালিক সকেটে পৌঁছে দেয়। সেক্ষেত্রে রুট ও প্রতিবেশী ঠিক আছে, এবং ব্যর্থতাটি স্থানীয় নেটওয়ার্কের ওপারের একটি হপের।

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

তাই সময় প্রমাণের অংশ। ত্রুটি কখন দেখা দিল, সকেট কোন পিয়ার ঠিকানা ব্যবহার করল, এবং টানেল কি সদ্য পুনঃসংযুক্ত হয়েছিল তা টুকে রাখুন। রুট পরিবর্তনের ঠিক পরে ঝাঁক স্থানীয় টেবিলের দিকে ইঙ্গিত করে; স্থিতিশীল প্রবাহের কয়েক মিনিট পরে একক ত্রুটি পথের প্রতিবেদনের দিকে ইঙ্গিত করে।

ক্রিপ্টো বদলানোর আগে স্তরগুলো আলাদা করুন

তিনটি প্রশ্ন ত্রুটিটিকে শ্রেণিবদ্ধ করে। কার্নেল কি গন্তব্য প্রত্যাখ্যান করে এমন রুট বেছেছে? এটি কি বৈধ রুট বেছেছে কিন্তু পরবর্তী হপ সমাধান করতে ব্যর্থ হয়েছে? নাকি স্থানীয় নেটওয়ার্কের বাইরে থেকে একটি প্রতিবেদন এসেছে? কেবল তৃতীয় ক্ষেত্রেই টানেলের দূর প্রান্ত জড়িত হতে পারে, এবং তখনও তা এনক্রিপশনকে জড়িত করে না।

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

প্রথম পরিবর্তনের আগে গন্তব্য, নেমস্পেস, নির্বাচিত টেবিল, পরবর্তী হপ, প্রতিবেশী অবস্থা ও ত্রুটির সময় লিখে রাখুন। সমাধানের পরে একই লুকআপ আবার চালান; এখন টানেলের দিকে নির্দেশ করা রুট ও এখন সমাধান হওয়া প্রতিবেশী এন্ট্রি অসম্পর্কিত ঠিকানায় সফল ping-এর চেয়ে শক্তিশালী প্রমাণ।