কেন একটি লোকাল রুট VPN-এর ডিফল্ট রুটকে হারিয়ে দেয়

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

সংযুক্ত প্রিফিক্স ডিফল্ট রুটের চেয়ে বেশি নির্দিষ্ট

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

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

কার্নেল যে পছন্দ করত সেটি পড়ুন

টেবিল উপর থেকে পড়ার বদলে কার্নেলকে জিজ্ঞাসা করুন নির্দিষ্ট গন্তব্যের জন্য সে কোন রুট ব্যবহার করত। তারপর দেখুন কোনো পলিসি রুল ভিন্ন টেবিল বেছে নিতে পারে কি না। দুটি কমান্ড কয়েক সেকেন্ডে দুটি প্রশ্নেরই উত্তর দেয়।

ip route get 10.20.30.41
ip route show table all | grep -E '10\.|default'
ip rule show

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

লোকাল অ্যাক্সেস আলাদা একটি অনুমতি

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

দুই স্তর ভিন্নভাবে ব্যর্থ হয়। আটকানো লোকাল পথ রুট থাকা সত্ত্বেও টাইমআউট দেয়, আর ওভারল্যাপিং রুট ভুল হোস্ট থেকে উত্তর দেয়। এদের আলাদা করতে একটাই কোয়েরি লাগে আর ফায়ারওয়াল বদলে একটি দুপুর বাঁচে, আর ফরওয়ার্ডিং ব্যবস্থা বর্ণিত হয়েছে strongSwan-এর ফরওয়ার্ডিং নোট-এ।

হোস্ট-রুটের স্তূপ না বানিয়ে ওভারল্যাপ ঠিক করুন

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

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