دو 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 کا دستی صفحہ منتخب کنندہ اور ترجیح کے معنی کی دستاویز کرتا ہے۔ اسے ہر پول کی تلاش جانچ کے ساتھ ملائیں اور ڈیزائن قابل جانچ ہو جاتا ہے، جو ایک سال چلنے والی پالیسی روٹنگ اور اس کے درمیان فرق ہے جسے سبھی چھونے سے ڈرتے ہیں۔