দুটি VPN পুলের জন্য উৎস রাউটিং: আপনার নিয়মটি কী মিস করে
from ধরনের নিয়ম SNAT পুনর্লিখনের আগেই ক্লায়েন্ট ঠিকানার সঙ্গে মেলে, আর গেটওয়ে থেকে করা পরীক্ষা কোনোটির সঙ্গেই মেলে না। প্রতি পুলে লুকআপ চালান এবং বদলে অগ্রাধিকার পড়ুন।
দুটি ক্লায়েন্ট পুল, একটি গেটওয়ে, আর পরিকল্পনাটি সহজ মনে হয়: একটি নিয়ম প্রথম পুলটিকে দ্রুত আপলিংক দিয়ে পাঠায়, আরেকটি দ্বিতীয় পুলটিকে পার্টনার টানেল দিয়ে পাঠায়। তারপর নিয়মগুলো বসানো হয়, তবু দ্বিতীয় পুলটি ডিফল্ট রুট দিয়েই বেরোয়। নিয়মটি ভাঙা নয়। প্যাকেটের উৎসটি লেখক যা ভেবেছিলেন তা নয়, কারণ অনুবাদ ও লুকআপ একই প্যাকেটের যাত্রার আলাদা দুই বিন্দুতে ঘটে, এবং ক্রমটি বেশিরভাগ মানুষ যে মানসিক চিত্র আঁকেন তার উল্টো।
লুকআপ ঘটে উৎস পুনর্লিখনের আগেই
VPN ক্লায়েন্ট থেকে ফরওয়ার্ড হওয়া প্যাকেটের জন্য কার্নেল একটি নির্দিষ্ট ক্রম চালায়। এটি টানেল ইন্টারফেসে আসে, prerouting-এ যায় যেখানে conntrack ও DNAT থাকে, তারপর রাউটিং সিদ্ধান্ত নেওয়া হয়, তারপর ফরওয়ার্ডিং, তারপর postrouting, যেখানে SNAT সবার শেষে প্রয়োগ হয়। from ধরনের নিয়ম ওই রাউটিং সিদ্ধান্তের সময় দেখা হয়, অর্থাৎ এটি ক্লায়েন্টের মূল ঠিকানা দেখে, অনূদিত ঠিকানা নয়।
তাই একটি masquerade নিয়ম যোগ করলে বহির্গামী ফ্লোতে কোন পলিসি মেলে তা বদলায় না। যা বদলায় তা হলো দূর প্রান্ত কী দেখে, এবং সেইসূত্রে কোন ফেরত পথ থাকে। এগুলো দুটি আলাদা পরিণতি, আর পরিবর্তন পর্যালোচনায় সবাই এদের গুলিয়ে ফেলে। এদের আলাদা করুন, দেখবেন নকশাটি সাধারণত এক মিনিটেই স্পষ্ট হয়ে যায়।
অনূদিত ঠিকানাটি নিয়মের মধ্যে দেখা যায় উত্তরের দিকেই। গেটওয়েতে ফিরে আসা প্যাকেটটি অনূদিত ঠিকানায় সম্বোধন করা থাকে, এবং যদি গন্তব্য বা যে ইন্টারফেস দিয়ে এটি এসেছে তার ভিত্তিতে পলিসি নিয়ম থাকে, তবে সেই মানটিই আপনার মেলানো হবে। একই সংযোগ, প্রতিটি দিকে ভিন্ন সত্যের উৎস।
| Stage | Source the kernel sees | What it means for your rule |
|---|---|---|
| Prerouting | Client address, 172.31.7.42 | Where marks and DNAT are applied |
| Routing decision | Still 172.31.7.42 | This is where from rules match |
| Postrouting | Becomes 198.51.100.9 | What the far end and its return route see |
সুতরাং ভিন্ন উৎসের দুটি পুলের সত্যিই আলাদা টেবিল দরকার, এবং নকশাটি সঠিক। উপরের টেবিলটি যে শর্টকাটটি বাতিল করে তা হলো, দূর সাইট কী পেল তা দেখে নিয়মটি অনুমান করে ডিবাগ করা।
গেটওয়ে থেকে করা পরীক্ষা পুলের পরীক্ষা নয়
গেটওয়ে নিজে যে ট্রাফিক তৈরি করে তা কখনও prerouting-এ যায় না, কারণ তা কোনো ইন্টারফেসে আসেনি। তা আউটপুট পথে রাউট হয়, উৎস হিসেবে গেটওয়ের নিজের ঠিকানা নিয়ে, এবং ক্লায়েন্ট রেঞ্জের উপর তৈরি from নিয়মটি মিলবে না। এই ক্ষেত্রে প্রতিটি টিকিট যা বলে যে বক্স থেকে কাজ করে কিন্তু ক্লায়েন্ট থেকে করে না, তা ওই তথ্যটিরই পুনর্কথন।
ক্লায়েন্টকে অনুমান না করে অনুকরণ করুন। রাউটিং লুকআপ সরাসরি জিজ্ঞাসা করা যায়, একটি উৎস ও একটি ইনগ্রেস ইন্টারফেস দিয়ে:
ip route get 198.51.100.9 from 172.31.7.42 iif tun0
ip route get 198.51.100.9 from 172.31.8.42 iif tun0
ip route show table 201প্রতি পুলে একবার চালান। যদি দুটি কমান্ড একই ইন্টারফেস ফেরত দেয়, তবে নিয়মগুলো পুল দুটিকে আলাদা করছে না, এবং কারণ হয় একটি অনুপস্থিত নিয়ম, নয়তো উভয়ের সঙ্গে মেলা উচ্চতর অগ্রাধিকারের নিয়ম। যদি ভিন্ন ইন্টারফেস ফেরত দেয় কিন্তু ক্লায়েন্ট তবু ব্যর্থ হয়, তবে ত্রুটি লুকআপের পরের ধাপে, এবং নিয়ম দেখা বন্ধ করতে পারেন।
অগ্রাধিকার, ফাইলে অবস্থান নয়
নিয়মগুলো অগ্রাধিকারের ঊর্ধ্বক্রমে মূল্যায়িত হয়, এবং সংখ্যাটিই মুখ্য, আপনি যে ক্রমে টাইপ করেছেন তা নয়। local টেবিল 0 অগ্রাধিকারে, main টেবিল 32766-এ আর ডিফল্ট নিয়ম 32767-এ, তাই ডিফল্ট অগ্রাধিকার দিয়ে যোগ করা নিয়ম তালিকার শেষের দিকে পড়ে এবং প্রায় সবকিছুর কাছে হেরে যায়।
ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201স্পষ্ট অগ্রাধিকার অভীষ্ট ক্রমটিকে ফাইলে ও পর্যালোচনায় দৃশ্যমান করে। এটি পরেও যোগ করা কোনো নিয়মকে নীরবে বিদ্যমান নিয়মের আগে লাফাতে বাধা দেয়, যা একটি কাজ করা পলিসি অসম্পর্কিত পরিবর্তনের পর কাজ করা বন্ধ করার সবচেয়ে সাধারণ কারণ।
অসম্পূর্ণ টেবিলের দিকে দেখানো মিলে যাওয়া নিয়মটি আরেকটি ফাঁদ। যদি টেবিল 201-এ ডিফল্ট রুট থাকে কিন্তু গন্তব্যের রুট না থাকে, প্যাকেটটি ফেলে দেওয়া হয় বা ভুল জায়গায় পাঠানো হয়, আর নিয়মটি এককভাবে পুরোপুরি সঠিক দেখায়। নিয়ম নয়, টেবিল পড়ুন। নিয়ম একটি নির্দেশক, আর খালি টেবিল হলো শূন্যের দিকে নির্দেশক।
ফেরত পথটিও থাকতেই হবে
উৎস পলিসি একটি নির্গমন বেছে দেয়। এটি ফেরত পথ তৈরি করে না। যদি দ্বিতীয় পুল পার্টনার টানেল দিয়ে বেরোয়, পার্টনারকে জানতে হবে 172.31.8.0/24-এ কীভাবে পৌঁছাবে, হয় গেটওয়ের দিকে ফেরত রুট দিয়ে, নয়তো এমন অনূদিত ঠিকানা গ্রহণ করে যা সে ইতিমধ্যে জানে।
এদের মধ্যে বাছাই দৃশ্যমান পরিণতিসহ একটি নকশা সিদ্ধান্ত। ক্লায়েন্ট রেঞ্জটি ফেরত রাউট করলে পার্টনারের কাছে প্রতি-ক্লায়েন্ট পরিচয় রক্ষা পায় এবং তাদের আপনার প্রিফিক্স গ্রহণ করতে হয়। অনুবাদ পুলটিকে একটি ঠিকানার আড়ালে লুকায় এবং পার্টনারকে শুধু সেই ঠিকানাটি গ্রহণ করতে হয়, যার দাম হলো আপনার ও তাদের লগ আর কে সংযুক্ত হয়েছিল তা নিয়ে মিলবে না।
যাই বাছুন না কেন, তা পুল সংজ্ঞার পাশে লিখে রাখুন। কেবল কারও স্মৃতিতে থাকা ফেরত রুট ঠিক সেই জিনিস যা পার্টনার ফায়ারওয়াল বদলানো পর্যন্ত টিকে থাকে, আর তারপর পুনর্গঠনে এক দিন লাগে।
পলিসিতে গেটওয়ের নিজের টানেল ধরে ফেলবেন না
ক্লায়েন্টের জন্য লেখা নিয়মগুলো গেটওয়ে যে ট্রাফিক তৈরি করে তার উপরেও প্রযোজ্য, যদি আপনি তা বাদ না দেন। মার্ক বা আউটপুট ইন্টারফেসের উপর তৈরি বিস্তৃত নিয়ম গেটওয়ের নিজের পার্টনার-সংযোগ ধরে ফেলতে পারে, আর তখন যে টানেল পলিসিটি বহন করে সেটিই পলিসি দিয়ে রাউট হয়। এতে লুপ বা আউটেজ হয় যা প্রোভাইডারের ত্রুটির মতো দেখায়।
প্রতিটি নিয়ম যতটা সম্ভব সংকীর্ণ করুন: উৎস প্রিফিক্স, ইনগ্রেস ইন্টারফেস, এবং যেখানে সমর্থিত সেখানে এমন মার্ক যা কেবল ক্লায়েন্ট প্যাকেট বহন করে। তারপর প্রতিটি নিয়ম পরিবর্তনের পর গেটওয়ের নিজের সংযোগ পরীক্ষা করুন, কারণ ব্যর্থতা আত্মনির্দেশক এবং ক্লায়েন্ট পরীক্ষায় দেখা যায় না।
ip-rule ম্যানুয়াল পৃষ্ঠা সিলেক্টর ও অগ্রাধিকারের অর্থ বর্ণনা করে। এটি প্রতি-পুল লুকআপ পরীক্ষার সঙ্গে মিলিয়ে নিন, নকশাটি যাচাইযোগ্য হয়ে ওঠে, আর এটাই এক বছর টেকা পলিসি রাউটিং আর সবাই যেটি ছুঁতে ভয় পায় সেই পলিসি রাউটিংয়ের পার্থক্য।