route-gateway আর redirect-gateway এক নয়: আসলে কী বদলায়
এই অপশনটি কেবল OpenVPN যে রুট ইনস্টল করে তার জন্য পরবর্তী হপ যোগায়। এটি মুছে ফেললে পুশ করা পূর্ণ টানেল বন্ধ হয় না, আর সমাধানটি থাকে রিডাইরেকশনে।
আপনার টানেল উঠে আসে, প্রাইভেট সাবনেট সাড়া দেয়, আর কেউ প্রোফাইল থেকে গেটওয়ে লাইনটি মুছে ফেললেও সাধারণ ব্রাউজিং এখনও VPN-এর ভেতরে হারিয়ে যায়। এই সমন্বয়টাই ভুল নির্দেশিকা সম্পাদনার ছাপ। যা সরানো হয়েছে তা ক্লায়েন্টকে তার ইনস্টল করা রুটের জন্য পরবর্তী হপ দিয়েছিল; যা ট্রাফিক ধরা চালিয়ে গেছে তা অন্য জায়গা থেকে এসেছে এবং সার্ভার পুশ করেছে। কভারেজ আর পরবর্তী হপ আলাদা কাজ, এবং এদের মধ্যে কেবল একটি ঠিক করে পাবলিক গন্তব্য টানেল ব্যবহার করবে কি না।
আপনি যে লাইন সরিয়েছেন তা পরবর্তী হপ ছিল, পলিসি সুইচ নয়
ক্লায়েন্ট যে প্রতিটি রুট ইনস্টল করে তার দিকে ইশারা করার জন্য একটি গেটওয়ে ঠিকানা দরকার, আর রুট নিজে ঠিকানা না বললে গেটওয়ে নির্দেশিকাই সেই ঠিকানার উৎস। এটি মুছে দিলে সেই রুটগুলোর আটকে যাওয়ার জায়গা থাকে না, তাই তারা হয় ইনস্টল হয় না, নয় এমন পথে পড়ে যা কোথাও নেয় না। প্রাইভেট সাবনেটই ঠিক সেই জিনিস যা এমন একটি রুট বহন করছিল।
এদিকে যে আচরণ টিকে গেছে তার লেখক অন্য: পুশ করা ব্লকের একটি রিডাইরেকশন অপশন, যা তার ফ্ল্যাগ অনুযায়ী সাধারণ আউটগোয়িং ট্রাফিককে টানেলে নিয়ে যায়। গেটওয়ে সরানো এটি বন্ধও করে না, দুর্বলও করে না। ফলাফল দুই অবস্থার মধ্যে সবচেয়ে খারাপ: পাবলিক ট্রাফিক এখনও ধরা পড়ছে আর যে প্রাইভেট গন্তব্য টানেলটিকে ন্যায্যতা দিয়েছিল তা এখন পৌঁছানোর বাইরে। এজন্যই একই মনোভাবে করা দ্বিতীয় সম্পাদনাও কিছুই বদলায় না।
চারটি লিভার, চারটি ভিন্ন কাজ
এই আলোচনায় চারটি নির্দেশিকা পরস্পরের বদলে উদ্ধৃত হয়, আর তাদের মধ্যে কেবল একটি কভারেজ নিয়ন্ত্রণ করে, অর্থাৎ কোন গন্তব্যগুলো আদৌ টানেল দিয়ে যাবে। দ্বিতীয়টি ঠিক করে রুটগুলো যে পরবর্তী হপ ব্যবহার করে, তৃতীয়টি একটি প্রিফিক্স ইনস্টল করে, আর চতুর্থটি সার্ভার যা পুশ করেছে তার সবকিছু ফেলে দেয়, স্থাপনার প্রয়োজনীয় প্রাইভেট রুটসহ। টেবিলটি তাদের নাম অনুযায়ী নয়, প্রশাসক কী বদলাতে চাইছেন সেই অনুযায়ী সাজায়, কারণ নামগুলোকেই বিভ্রান্তির কারণ। এগুলোকে চারটি আলাদা সিদ্ধান্ত ভাবুন এবং আপনি সত্যিই যেটি উল্টাতে চান সেটি বেছে নিন।
বাস্তবে চারটিই প্রায়ই একটি পুশ করা ব্লকে লাইন ধরে ধরে আসে, যা তাদের একটিমাত্র সেটিংয়ের অংশ বলে দেখায়। তারা তা নয়, আর OpenVPN রেফারেন্স ঠিক সেই কারণেই তাদের আলাদা প্রক্রিয়া হিসেবে নথিভুক্ত করে। আপনি কোন সিদ্ধান্ত উল্টাচ্ছেন তা বের করা কাজ; সম্পাদনা এক লাইন।
| What you are trying to change | Directive that decides it | What it leaves alone |
|---|---|---|
| Which destinations use the tunnel | redirect-gateway | Per-prefix routes and resolver choice |
| The next hop a pushed route points at | route-gateway | Coverage of public destinations |
| One reachable prefix | route | Every other destination, default path included |
| All pushed routing and DNS at once | route-nopull | Nothing, which is the problem |
পুশ করা লাইন ফিল্টার করুন, পরবর্তী হপ রাখুন
আপনি যে কভারেজে আপত্তি করছেন তা যদি পুশ করা অপশন হিসেবে আসে, সংকীর্ণ প্রতিক্রিয়া হলো সেই অপশনটিকে নাম ধরে উপেক্ষা করা এবং পুশ করা ব্লকের বাকিটা অক্ষত রাখা। ফিল্টার হিসেবে লিখলে এটি নিচের লাইনের মতো দেখায়, আর এর জায়গা আক্রান্ত ক্লায়েন্টের প্রোফাইলে, সার্ভার কনফিগারেশনে নয়।
pull-filter ignore "redirect-gateway"সংকীর্ণতাই মূল কথা। যেহেতু ফিল্টার একটি টেক্সট প্রিফিক্স তুলনা করে, ছোট প্যাটার্ন পরবর্তী-হপ নির্দেশিকার সাথেও মেলে, যা ঠিক সেই তথ্য ছিনিয়ে নেয় যার ওপর প্রাইভেট রুটগুলো নির্ভর করে এবং মূল ভুলটিকে নতুন পোশাকে পুনরাবৃত্তি করে। ফিল্টার কেবল পুশ করা অপশনে কাজ করে, তাই স্থানীয়ভাবে লেখা বা নেটওয়ার্ক ম্যানেজার আরোপিত সমতুল্য লাইন কখনও স্পর্শ করে না। এরপর আবার সংযোগ করুন, কারণ জীবন্ত সেশন সার্ভার কী পুশ করেছে তা পুনরায় মূল্যায়ন করে না।
টেবিল নয়, লুকআপ পড়ুন
প্রোফাইল রিলোড করার পর কার্নেলকে জিজ্ঞাসা করুন দুটি গন্তব্য আসলে কোথায় যাবে: একটি প্রাইভেট প্রিফিক্সের ভেতরে আর একটি পাবলিক ইন্টারনেটে। মূল টেবিলের পূর্ণ ডাম্প পড়া কঠিন এবং ভুল পড়া সহজ, কারণ একটি রুট থেকে যেতে পারে এবং তবুও আরও নির্দিষ্ট মিলের কাছে হারতে পারে। পলিসি রাউটিংয়ের ক্ষেত্রে নিয়ম, টেবিল এবং সোর্স ঠিকানাও যাচাইয়ের অন্তর্ভুক্ত।
ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule showdef1 ভ্যারিয়েন্টের সাথে পরিচিতি দরকার, কারণ এটি পুরোনো ডিফল্ট এন্ট্রি দৃশ্যমান রাখে যদিও এক জোড়া অর্ধ-ডিফল্ট লুকআপে জিতে যায়। তাই আউটপুটে একটি 0.0.0.0/0 লাইন নিজে থেকে কিছুই প্রমাণ করে না। লুকআপ সেই প্রশ্নের উত্তর দেয় যা তালিকাটি কেবল উত্তর দিতে বলে মনে হয়।
DNS, IPv6 আর প্রাইভেট রুট এখনও কাজ করতে হবে
একটি IPv4 রিডাইরেকশন প্রত্যাখ্যান করা রিজলভার সম্পর্কে কিছুই বলে না, তাই একটি পুশ করা DNS অপশন রুটগুলো ঠিক দেখালেও প্রশ্নগুলো টানেলে পাঠাতে পারে। একটি IPv6 ডিফল্ট IPv4 যাচাই কখনও স্পর্শ করেনি এমন ঠিকানা পরিবারের জন্য একই কাজ করতে পারে। দুটোরই অনুমানের বদলে স্পষ্ট সিদ্ধান্ত দরকার। তারপর নিশ্চিত করুন প্রাইভেট সার্ভিস এখনও সাড়া দেয়, কারণ প্রাইভেট রুট হারানো স্প্লিট টানেল স্প্লিট টানেল নয়, ভাঙা টানেল।
একটি প্রশস্ততর টুল সতর্কতার যোগ্য: route-nopull প্রতিটি পুশ করা রুট ও পুশ করা DNS অপশন ফেলে দেয়, যা নিশ্চিতভাবে পূর্ণ টানেল থামায় এবং ঠিক তেমনই নিশ্চিতভাবে স্থাপনা যে প্রাইভেট রুটের ওপর নির্ভর করে তা ভাঙে, তাই এটি একটি অপশনের দিকে তাক করা নাম-ফিল্টারের চেয়ে অনেক বড় হাতুড়ি। যেকোনো পরিবর্তনের পর প্রাইভেট গন্তব্য, একটি পাবলিক গন্তব্য ও রিজলভার যাচাই করুন, আর সম্পন্ন হ্যান্ডশেককে হ্যান্ডশেক ছাড়া আর কিছুর প্রমাণ ভাববেন না।