রাউটিং টেবিল বনাম প্রকৃত লুকআপ: VPN ট্রাফিক কোথায় যায়

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

টেবিল হলো প্রার্থীর সমষ্টি, কোনো সিদ্ধান্ত নয়

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

তাই প্রথম পদক্ষেপ তালিকা পড়ার বদলে কার্নেলকে জিজ্ঞাসা করা। লুকআপ কমান্ড একটি গন্তব্যের উত্তর দেয়, এবং উৎস আর্গুমেন্টসহ এটি ঠিক সেই জোড়ার উত্তর দেয় যা একটি ফরওয়ার্ডেড বা বাউন্ড সংযোগ ব্যবহার করত:

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

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

লুকআপ আগে নিয়ম, তারপর টেবিল পরিক্রমা করে

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

ip rule show
ip route show table all | head -40
ip route show table 100

যদি একটি নিয়ম আপনার VPN পুল থেকে ট্রাফিক টেবিল 100-এ পাঠায়, তবে টেবিল 100-ই গুরুত্বপূর্ণ, এবং মূল টেবিল একটি ফাঁদ। এটিই রাউটারে উৎস-ভিত্তিক রাউটিংয়ের প্রক্রিয়া: একই গন্তব্যের দুটি ভিন্ন উত্তর থাকতে পারে প্যাকেট কোথা থেকে এসেছে তার উপর নির্ভর করে, এবং কেবল উৎস আর্গুমেন্টসহ লুকআপ প্রকাশ করে কোনটি প্রযোজ্য।

IPv6-এর নিজস্ব নিয়ম ও টেবিল আছে। যে ডিজাইন দুই পরিবারই চালায় তার দুটি লুকআপই দরকার, এবং কাজ করা IPv4 উত্তর v6 পথ সম্পর্কে কিছুই বলে না যা একটি ডুয়াল-স্ট্যাক ক্লায়েন্ট পছন্দ করতে পারে।

VPN ক্লায়েন্ট কী ইনস্টল করে

ক্লায়েন্টরা সাধারণত ডিফল্ট রুট প্রতিস্থাপন করে না, কারণ তা টানেলের নিজস্ব বাইরের পথ ভেঙে দেবে। তারা আরও নির্দিষ্ট কিছু ইনস্টল করে যা প্রিফিক্স দৈর্ঘ্যে জেতে: 0.0.0.0/1 এবং 128.0.0.0/1 কভার করা এক জোড়া অর্ধ-ডিফল্ট হলো ক্লাসিক কৌশল, কারণ দুটিই 0.0.0.0/0-এর চেয়ে দীর্ঘ প্রিফিক্স এবং একসাথে পুরো স্থান কভার করে। অন্যরা নির্দিষ্ট প্রাইভেট প্রিফিক্স প্লাস একটি নীতি নিয়ম ইনস্টল করে, এবং কেউ কেউ একটি মার্ক যোগ করে যাতে কেবল নির্বাচিত ট্রাফিক ধরা পড়ে।

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

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

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

বাইরের রুটও টিকে থাকতে হবে

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

পিয়ারের ঠিকানাটি যেভাবে ভিতরের গন্তব্য পরীক্ষা করেছেন সেভাবেই পরীক্ষা করুন, এবং নিশ্চিত করুন যে এটি টানেলের বদলে ফিজিক্যাল ইন্টারফেসে রিজলভ করে:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

একটি পুনরাবৃত্ত রুট, পিয়ারকে ধরার একটি নীতি নিয়ম, বা একটি পূর্ণ-টানেল ক্লায়েন্ট দ্বারা প্রতিস্থাপিত ডিফল্ট—এই তিনটিই সাধারণ কারণ। তিনটিই বাইরের লুকআপে দৃশ্যমান, এবং কোনোটিই ঘটনার পরে নেওয়া মূল টেবিলের ডাম্পে দৃশ্যমান নয়।

রাউটিং আউটপুট আপনাকে কী বলতে পারে না

সঠিক লুকআপ মানে কার্নেল প্যাকেটটি যুক্তিসঙ্গত কোথাও পাঠাবে। এর মানে নয় যে ফায়ারওয়াল তা অনুমোদন করে, IPsec নীতি তা কভার করে, NAT নিয়ম তা অনুবাদ করে, বা দূর পক্ষের ফেরত রুট আছে। এর প্রত্যেকটি পরবর্তী ধাপ, এবং strongSwan ফরওয়ার্ডিং নোট উভয় প্রান্তে প্যাকেটকে যে শৃঙ্খল অতিক্রম করতে হয় তা বর্ণনা করে।

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

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