সমান খরচের রুট কেন VPN ত্রুটি দেখা কঠিন করে তোলে
যখন একাধিক টানেল একই খরচ ভাগ করে, প্রতিটি ফ্লো ভিন্ন একটি নিতে পারে। সফল ping আপনার অ্যাপ্লিকেশন সত্যিই যে পথ ব্যবহার করে সে সম্পর্কে কিছুই বলে না।
একজন ব্যবহারকারী জানান, অভ্যন্তরীণ অ্যাপ্লিকেশনটি এক মেশিন থেকে কাজ করে আর অন্য মেশিন থেকে ব্যর্থ হয়, অথচ গেটওয়ে থেকে চালানো ping দুই ক্ষেত্রেই সফল। সমান খরচের একাধিক টানেল থাকলে এটি কোনো বিরোধ নয়। প্রতিটি ফ্লো তার নিজের পরবর্তী হপে বসানো হয়, তাই আপনার প্রোব এবং ব্যবহারকারীর সেশন সহজভাবে ভিন্ন পথ ব্যবহার করতে পারে। নিচের আলোচনা কিছু পরিবর্তনের আগে সেই বাছাইটি পুনরুৎপাদন করে।
একটি ping, কয়েকটি সম্ভাব্য পথ
একটি রুটে একই খরচে একাধিক পরবর্তী হপ থাকলে রাউটারকে প্রতি প্যাকেটে একটি বেছে নিতে হয়। অধিকাংশ বাস্তবায়ন প্যাকেটের ক্ষেত্র হ্যাশ করে, সাধারণত উৎস ও গন্তব্য ঠিকানা এবং প্রোটোকল ও পোর্ট, যাতে প্রতিক্রিয়া একই পথে থাকে। ভিন্ন অ্যাপ্লিকেশন, এমনকি একই অ্যাপ্লিকেশনের ভিন্ন সংযোগও ভিন্ন হ্যাশ তৈরি করে।
সেজন্যই গেটওয়ে থেকে নেওয়া ডায়াগনস্টিক এত কম প্রমাণ করে। গেটওয়ের নিজের প্রোবের নিজস্ব ঠিকানা ও পোর্ট আছে, ফলে নিজস্ব হ্যাশও। এটি সুস্থ টানেলে পড়তে পারে, আর ব্যবহারকারী ভাঙা টানেলেই পড়তে থাকে।
প্ল্যাটফর্ম কীভাবে পরবর্তী হপ বেছে নেয়
অনুমান না করে বাছাইটি পুনরুৎপাদন করুন। কার্নেলকে জিজ্ঞাসা করুন, ব্যর্থ সেশনটির মতো একই উৎস ও গন্তব্যের জন্য সে কোন রুট ব্যবহার করবে। সেই অনুসন্ধানে এমন ক্ষেত্র থাকে যা সাধারণ গন্তব্য-অনুসন্ধান উপেক্ষা করে। একটি কার্যকর ক্লায়েন্ট থেকেও এটি চালান এবং দুই উত্তর মেলান:
ip route get 10.20.5.7 from 10.20.0.14নতুন iproute2 সংস্করণ প্রোটোকল ও গন্তব্য পোর্টও গ্রহণ করে, যা গুরুত্বপূর্ণ যখন হ্যাশে সেগুলো থাকে। সেই আউটপুট একটি কার্যকর ক্লায়েন্ট থেকে একই অনুসন্ধানের সঙ্গে মেলান, আর পার্থক্যটাই আপনার অনুপস্থিত প্রমাণ।
| Observation | Likely cause | First check |
|---|---|---|
| Ping works, application fails | A different flow hash selects another tunnel | Per-flow lookup from the client's address |
| Some users fail, others do not | One tunnel lacks a prefix or selector | Compare both tunnels' installed routes |
| Fails only at larger sizes | Tunnels have different effective MTU | Probe the same size over each path |
| Fails after a reconnect | Stateful asymmetry between paths | Session state on both gateways |
ব্যর্থ ফ্লো ধরে চলুন, রুট টেবিল নয়
রুট টেবিল দুই টানেলই তালিকাভুক্ত করে এবং সংজ্ঞা অনুসারেই সঠিক দেখায়। প্রশ্ন হলো, নির্বাচিত হওয়ার পর প্রতিটি টানেল প্যাকেটটি নিয়ে কী করে। যাচাই করুন, দুটোই একই সুরক্ষিত প্রিফিক্স, একই ফরওয়ার্ডিং অনুমতি এবং একই ক্লায়েন্ট পর্যন্ত পৌঁছানো ফেরত পথ বহন করে।
মাঝখানে থাকা স্টেটধারী ডিভাইসে নজর দিন। যদি কোনো অনুরোধ এক টানেল দিয়ে বেরিয়ে যায় আর উত্তর আসে অন্য টানেলে, তাহলে যে ফায়ারওয়াল বা NAT মূল ফ্লোটি কখনো দেখেনি, সেটি তা ফেলে দেবে. দুই টানেলই ট্রাফিক সঠিকভাবে ফরওয়ার্ড করে, তবু সংযোগটি ব্যর্থ হয়।
প্রতিটি পথে MTU-ও দেখুন। অতিরিক্ত এনক্যাপসুলেশনের পথ ব্যবহারযোগ্য আকার কমিয়ে দেয়, আর এক টানেলে সফল স্থানান্তর অন্য টানেলে ঠিক সেই আকারেই আটকে যায় যেখানে ছোটটি ভাঙে।
একবারে একটি পথ মেলান
যেখানে নকশা রক্ষণাবেক্ষণ অনুমোদন করে, সেখানে একটি টানেল সেবা থেকে সরিয়ে ব্যবহারকারীর কাজটি পুনরাবৃত্তি করুন। ব্যর্থতা যদি আর না থাকে, সমস্যাটি সরানো পথেরই, আর পরের ধাপ হলো তার কনফিগারেশন প্রতিবেশীর সঙ্গে মেলানো, রাউটিং টেবিল আবার পরীক্ষা করা নয়।
বারবার ping নয়, আসল অ্যাপ্লিকেশনটাই মেলান। লিপিবদ্ধ করুন ব্যর্থতা কোনো নির্দিষ্ট পরবর্তী হপ, প্যাকেট আকার নাকি পুনঃসংযোগের পরের পরিবর্তন অনুসরণ করে, কারণ এই তিন ধরন ভিন্ন মেরামতের দিকে ইশারা করে।
শেষে লিখে রাখুন কেন পথগুলো সমতুল্য ধরা হয় এবং ব্যর্থতা কীভাবে একটিকে সেবা থেকে সরাবে। মাল্টিপাথ নিরাপদ কেবল তখনই, যখন পথগুলো সত্যিই বিনিময়যোগ্য, আর এটি একটি নকশা-বিবৃতি যা ধরে নেওয়ার বদলে যাচাই করা উচিত।