অ্যাকাউন্টভিত্তিক রাউটিং তখনই মানায় যখন একজন Linux ব্যবহারকারীর মালিকানার প্রতিটি IPv4 সকেট একটি বিদ্যমান টানেল দিয়ে বের হওয়া উচিত, আর এটি মানায় না যখন আপনার প্রোগ্রাম-স্তরের বিচ্ছিন্নতা দরকার। এটি UID দিয়ে বেছে নেয়, তাই ওই অ্যাকাউন্টে চলা সবকিছুই পরিধিতে পড়ে, এমনকি যে ব্যাচ কাজটি আপনি ভুলে গেছেন সেটিও। একটি ip rule স্পর্শ করার আগেই ওই প্রশ্নটি নিষ্পত্তি করুন।

নিচের উদাহরণে UID 1500-এ একটি নিবেদিত ব্রাউজার অ্যাকাউন্ট, 10.80.0.11 লোকাল ঠিকানা বহনকারী একটি টানেল ডিভাইস tun-office, এবং প্রশ্নবিদ্ধ গন্তব্যগুলোকে অনুমোদনকারী একটি VPN ধরে নেওয়া হয়েছে। ডেমনটি নিজে ওই UID-এর বাইরে চলে।

যে তিনটি শর্ত প্রক্রিয়াটি বেছে দেয়

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

যে ভুলটি এড়াতে হবে তা হলো লঞ্চার মালিক নির্ধারণ করে ধরে নেওয়া। অন্য ব্যবহারকারীর সেশন থেকে URL পাওয়া ব্রাউজার UID 1500-এর অধীনে সকেট তৈরি করেনি, আর কোনো নিয়মই তার তৈরি ট্রাফিক সরাবে না।

টেবিল, নিয়ম ও প্রাহরিক

বিদ্যমান নিয়ম যাচাই করে অব্যবহৃত টেবিল ও অগ্রাধিকার নম্বর বেছে নেওয়ার পর ব্যবস্থাটি সংক্ষিপ্ত: টানেলের উৎস ঠিকানা বহনকারী একটি নিবেদিত টেবিলে ডিফল্ট রুট, অ্যাকাউন্টের লুকআপগুলোকে ওই টেবিলে পাঠানো একটি নিয়ম, এবং ফলব্যাক আটকানো একটি সমাপ্তিকারী নিয়ম। লিখিতভাবে এটি একটি ইডেম্পোটেন্ট রুট প্রতিস্থাপন, ip -4 route replace default dev tun-office src 10.80.0.11 table 51820, এরপর ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820।

প্রাহরিকটি হলো ip -4 rule add priority 12101 uidrange 1500-1500 unreachable, আর এর দৈর্ঘ্য যা ইঙ্গিত করে তার চেয়ে এটি বেশি গুরুত্বপূর্ণ। এটি ছাড়া 51820 টেবিলে অনুপস্থিত রুট সাধারণ আপলিংকে গিয়ে পড়ে এবং অ্যাকাউন্টটি নীরবে সেই ট্রাফিক ফাঁস করে যা নীতিটি ধরার কথা ছিল। এটি থাকলে একই ব্যর্থতা টাইমআউটে পরিণত হয়, অর্থাৎ ফলব্যাক নয় বরং ব্লকিং।

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

UID রাউটিং যা বাদ দেয়: DNS

রিজলভার ডেমন তার আপস্ট্রিম সকেট নিজের UID-এর অধীনে খোলে, তাই 1500 বেছে নিলে ওই কোয়েরিগুলো 51820 টেবিলে যায় না। DNS সমন্বয় আলাদা সিদ্ধান্ত: অ্যাকাউন্টটিকে টানেল দিয়ে পৌঁছানো যায় এমন রিজলভারে নির্দেশ করুন, অথবা মেনে নিন নাম-সমাধান হোস্টের পথ অনুসরণ করে আর ট্রাফিক করে না।

লোকাল স্টাবে loopback কোয়েরি এই প্রমাণ নয় যে আপস্ট্রিম কোয়েরি ব্রাউজারের রুট ব্যবহার করেছে, ক্যাশ থেকে সফল পৃষ্ঠা লোডও নয়।

IPv6-এর ডিজাইনে নিজের বাক্য দরকার

উপরের নিয়মগুলো কেবল IPv4 কভার করে। যদি প্রয়োজন হয় এই অ্যাকাউন্ট থেকে সরাসরি IPv6 ছাড়া একটি IPv4 টানেল, তাহলে পর্যালোচিত সমাপ্তিকারী নিয়ম যোগ করুন যেমন ip -6 rule add priority 12101 uidrange 1500-1500 unreachable, তারপর আগের IPv6 নিয়ম এবং যে loopback ব্যতিক্রমগুলো রাখতে চান তা যাচাই করুন।

সরাসরি IPv6 আটকানো ডুয়াল-স্ট্যাক টানেলিং নয়; এটি একটি সীমানা। এটিকে টানেলিং বলা পরের যে ব্যক্তি নীতিটি পড়বেন তাকে বিভ্রান্ত করবে, আর সেই বিভ্রান্তি ভাঙা IPv6 সাইট নিয়ে হেল্পডেস্ক টিকিট হিসেবে ফুটে উঠবে।

প্রকৃত অ্যাকাউন্ট দিয়ে যাচাই করুন, তারপর জীবনচক্রের দায়িত্ব নিন

লুকআপ তুলনা করুন: একই গন্তব্যে সাধারণ UID দিয়ে ip -4 route get 198.51.100.25 uid 1500। তারপর নিবেদিত অ্যাকাউন্টের অধীনে একটি অনুমোদিত অনুরোধ করুন এবং দূরপ্রান্ত যে উৎস ঠিকানা দেখে তা যাচাই করুন। পছন্দের উৎস ঠিকানা source NAT নয়, এবং এটি অন্য কিছু বাইন্ড করা অ্যাপ্লিকেশনকে অগ্রাহ্য করবে না। যদি দুই লুকআপই একই পথ ফেরত দেয়, নিয়মটি আপনি যা ভাবছেন তা করছে না।

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

সম্পর্কিত নিবন্ধ