যখন স্প্লিট টানেলের রুটগুলো ওভারল্যাপ করে: কোন প্রিফিক্স জেতে

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

1. গন্তব্য ও উৎস লিখুন

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

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

2. কার্নেলকে জিজ্ঞাসা করুন কোন রুটটি বেছে নিয়েছে

রুট টেবিল পড়ে উত্তর অনুমান করবেন না। স্ট্যাক যে প্রশ্ন করে সেই একই প্রশ্ন একই উৎস ঠিকানা দিয়ে করুন: Linux-এ ip route get 10.20.4.10 from 10.8.0.2, বা PowerShell-এ Find-NetRoute -RemoteIPAddress 10.20.4.10। আউটপুট যে রুটটি সত্যিই ব্যবহার হবে তা নাম দেয়, এবং সেটি প্রায়ই টেবিল পড়ার সময় আপনি যা আশা করেছিলেন তা নয়।

মিলে যাওয়া রুটগুলোর মধ্যে সাধারণত আরও নির্দিষ্ট প্রিফিক্স জেতে: দুটোরই ভেতরে থাকা ঠিকানার জন্য /24, /16-কে হারায়। একই দৈর্ঘ্যের মিলগুলোর মধ্যে কম মেট্রিক জেতে, এবং বন্ধ লিঙ্কে বসানো রুট বাদ দেওয়া হয়। একই /24 একই মেট্রিক দিয়ে ঠেলে দেওয়া দুটি টানেল ভিন্ন ঘটনা: কার্নেল দুটি রুটই রাখে এবং তাদের মধ্যে বেছে নেয়, তাই ফলাফল ক্লায়েন্ট যুক্ত হওয়ার ক্রম অনুসরণ না করে বদলাতে পারে। সোমবার-চলে-মঙ্গলবার-ব্যর্থ-হয় এই ধরনটি তৈরি করে ঠিক এই পরিস্থিতিই, এবং অন্য ক্রমে আবার সংযোগ করলে তা বদলায় না।

3. পরীক্ষা করুন কোনও নীতি নিয়ম অনুসন্ধানটিকে অন্যদিকে ঘুরিয়েছে কিনা

রুট টেবিল দেখার আগে কার্নেল তার নীতি নিয়মগুলো অতিক্রম করে। একটি নিয়ম নির্দিষ্ট উৎস, ব্যবহারকারী বা ফায়ারওয়াল চিহ্ন থেকে আসা ট্রাফিককে সম্পূর্ণ অন্য টেবিলে পাঠাতে পারে, তাই মূল টেবিলের জেতা প্রিফিক্স সেই প্রবাহের জন্য কখনোই নাও দেখা হতে পারে। ip rule show সেগুলো মূল্যায়ন ক্রমে তালিকাভুক্ত করে, এবং ip route show table 100 দেখায় বাছাই করা টেবিলে আসলে কী আছে।

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

4. রুটের সমতা ও নকল ঠিকানা পরিকল্পনা আলাদা করুন

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

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

5. নিশ্চিত করুন সমাধানকারী রুটের সঙ্গে একমত

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

সমাধানকারীকে সরাসরি জিজ্ঞাসা করুন এবং উত্তর দেওয়া সার্ভারটি লিখে রাখুন। সংক্ষিপ্ত TTL-যুক্ত ক্যাশে উত্তর এটাও ব্যাখ্যা করতে পারে কেন পুনরায় সংযোগের পরে প্রথম অনুরোধ পঞ্চমটির থেকে আলাদা আচরণ করে।

6. আবার সংযোগ করুন, প্রয়োগ করা অবস্থা দেখুন, তারপর দুই প্রবাহ পরীক্ষা করুন

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

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