ٹنل کے ذریعے دور دراز /24 تک پہنچنا: NETMAP، DNAT یا راستہ؟
پورے پریفکس کو NETMAP سے میپ کریں، ہر ہوسٹ کے لیے DNAT قواعد شامل کریں یا اصل رینج کو روٹ کریں، اور اس بنیاد پر فیصلہ کریں کہ دور والے جانب کو کیا دیکھنا ہے اور کون ٹریفک شروع کر سکتا ہے۔
ٹنل کے آخری نقطے کے پیچھے موجود ذیلی نیٹ تک آپ تین طریقوں سے پہنچ سکتے ہیں، اور ایک منٹ کی حقائق جمع کرنا عام طور پر دو کو خارج کر دیتا ہے۔ حقائق یہ ہیں: کیا وہاں کے سرورز کو صارفین میں فرق کرنا ہے، کیا وہاں سے کوئی کبھی آپ کی رینج کی طرف رابطہ کرے گا، اور دور والے راؤٹر کو کون تبدیل کر سکتا ہے۔ ان تینوں کا جواب دیں اور ڈیزائن خود منتخب ہو جاتا ہے۔ باقی فرض کرتا ہے کہ آپ آخری نقطہ چلاتے ہیں اور اس کا فائر وال تبدیل کر سکتے ہیں۔
تین آپشنز، اور ہر ایک حقیقت میں کیا بدلتا ہے
پریفکس میپنگ، ہر ہوسٹ کے لیے DNAT اور روٹ شدہ پریفکس سب ایک ہی دو رینجوں کے درمیان پیکٹ منتقل کرتے ہیں، لیکن مختلف چیزیں بدلتے ہیں۔ میپنگ ایک عرفی رینج ایجاد کرتی ہے اور سفر کے دوران پتوں کو ریاضیاتی طور پر دوبارہ لکھتی ہے۔ ہر ہوسٹ کے قواعد بھی دوبارہ لکھتے ہیں، صرف یہ کہ ہر منزل کا نام ہاتھ سے دیا جاتا ہے۔ روٹ شدہ پریفکس کچھ بھی دوبارہ نہیں لکھتا: پیکٹ اصل پتے برقرار رکھتے ہیں اور دونوں سرے اس بات پر متفق ہیں کہ یہ پتے کہاں رہتے ہیں۔
| What the far side needs | Prefix mapping | Per-host DNAT | Routed prefix |
|---|---|---|---|
| Users visible to its logs | Only without source NAT | Same condition | Yes, unchanged |
| To start a connection toward you | No, alias is local | No, same reason | Yes, both ends route |
| To absorb a new host | Yes, arithmetic only | No, one rule per address | Yes, it simply routes |
| To require no config change | Yes, with source NAT | Yes, same condition | No, it needs a route back |
اخراج کا آغاز دور والے جانب سے کریں، جہاں پابندیاں بدلنا سب سے مشکل ہے۔ اگر وہاں کا سرور کلائنٹ کے پتے لاگ میں لکھتا ہے، انہیں اجازت شدہ فہرست سے جانچتا ہے یا کسی اور نظام کے حوالے کرتا ہے، تو ماخذ کا ترجمہ اس کی واحد شناخت ختم کر دیتا ہے۔ اگر دور والے جانب کو بھی اندر رابطہ کرنا ہو، تو ترجمہ بالکل خارج ہے، کیونکہ وہاں کسی کو معلوم نہیں کہ عرف موجود ہے۔ صرف تب جب دور والا جانب محض درخواستوں کا جواب دیتا ہے، سستے آپشنز محفوظ ہوتے ہیں۔
پریفکس کے جوڑے، اور سائز کیوں مطابقت رکھنے چاہئیں
NETMAP nat جدول کا ہدف ہے جو ایک ہی لمبائی کے پریفکس کے جوڑے پر کام کرتا ہے۔ اس کے اندر ہر پتے کے لیے جدول نہیں: یہ پریفکس اتارتا ہے، ہوسٹ بٹس رکھتا ہے اور انہیں نئے پریفکس سے دوبارہ جوڑتا ہے، اسی لیے /24 /24 پر میپ ہوتا ہے اور کبھی /25 پر نہیں۔ مقام سمت کا تعین کرتا ہے: PREROUTING میں منزل کی مطابقت دوبارہ لکھتی ہے کہ پیکٹ کہاں جاتا ہے، اور POSTROUTING میں ماخذ کی مطابقت دوبارہ لکھتی ہے کہ یہ کہاں سے آیا۔
192.168.2.17 پر ہوسٹ آپ کے کلائنٹس کو 10.50.1.17 کے طور پر دکھائی دیتا ہے، اور آخری آکٹٹ سجاوٹ نہیں — یہ دونوں جانب ایک ہی عدد ہے۔ کل 192.168.2.40 پر ہوسٹ شامل کریں، اس کا عرف 10.50.1.40 ہوگا، تبدیل کرنے کے لیے کوئی قاعدہ نہیں۔
کلائنٹس کو عرفی رینج کے لیے آپ کے باکس کی طرف اشارہ کرنے والا راستہ اب بھی درکار ہے، الا یہ کہ عرف اس ذیلی نیٹ میں ہو جس تک وہ پہلے ہی پہنچتے ہیں۔ گیٹ وے کو عرف کے لیے راستے کی ضرورت نہیں، کیونکہ منزل کا ترجمہ راستے کی تلاش سے پہلے PREROUTING میں ہوتا ہے۔ فارورڈنگ بھی فعال ہونی چاہیے، ورنہ کرنل دوبارہ لکھنے کے بعد پیکٹ گرا دیتا ہے۔ نیچے دیے گئے تین کمانڈز br0 پر کلائنٹس، 10.50.1.0/24 پر عرف اور tun0 پر ٹنل والے Debian طرز کے گیٹ وے پر پوری ترتیب ہیں۔
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i br0 -d 10.50.1.0/24 -j NETMAP --to 192.168.2.0/24
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADEجواب کو خود واپسی کا راستہ تلاش کرنا ہوگا
منزل دوبارہ لکھنا صرف یہ طے کرتا ہے کہ پیکٹ کہاں پہنچایا جائے گا۔ دور والے سرور کو پھر بھی ایسے پتے کا جواب دینا ہے جہاں تک وہ پہنچتا ہے، اور اسے دو طریقوں سے ترتیب دیا جا سکتا ہے۔ ماخذ کا ترجمہ کریں تاکہ جوابات آپ کے باکس کی طرف لوٹیں، یا ماخذ کو چھوڑ دیں اور دور والے جانب کو کلائنٹ رینج کے لیے راستہ دیں۔
باہر جانے کی سمت masquerade چھوٹا راستہ ہے: POSTROUTING میں ایک قاعدہ اور دور والا جانب آپ کا ٹنل پتہ دیکھتا ہے، اس لیے اسے اپنا راستہ درکار نہیں۔ قیمت یہ ہے کہ ہر صارف ایک ہی پتے میں سمٹ جاتا ہے، اور فی صارف لاگ بے معنی ہو جاتے ہیں۔ ماخذ کو اچھوتا چھوڑنے سے وہ معلومات محفوظ رہتی ہیں، لیکن پھر دور والی سائٹ کو کلائنٹ رینج کے جوابات ٹنل کے ذریعے واپس بھیجنے ہوں گے۔OpenVPN سرور پر یہ push کیا گیا push "route 10.50.9.0 255.255.255.0"، نیز route 192.168.2.0 255.255.255.0 سطر ہے۔
مہنگی ناکامی ہر ایک کا آدھا کرنا ہے۔ اگر آپ کچھ ٹریفک masquerade کرتے ہیں جبکہ دور والا جانب دوسرے ٹریفک کے لیے واپسی کا راستہ بھی اٹھائے ہوئے ہے، تو جوابات ایسے انٹرفیس پر آتے ہیں جہاں کنکشن ٹریکنگ اندراج کبھی نہیں دیکھا گیا۔ کلائنٹ اس درخواست کے لیے ٹائم آؤٹ رپورٹ کرتا ہے جسے سرور نے خدمت شدہ درج کیا۔ ایک بہاؤ کی دونوں سمتیں ایک ہی netfilter مثال سے گزرنی چاہئیں: ایک گیٹ وے ترجمہ کرتا ہے، سلسلے میں دو فائر وال نہیں۔
conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -nاندراج دونوں سمتوں میں پڑھیں: اصل tuple منزل پر آپ کا عرف رکھتا ہے، جبکہ جواب کا tuple اصل پتہ اٹھاتا ہے۔ اگر جواب کا tuple نہ ہو تو مسئلہ قاعدہ نہیں، واپسی کا راستہ ہے۔ اگر PREROUTING کاؤنٹرز کبھی نہ ہلے، تو پیکٹ اس hook تک کبھی نہیں پہنچا۔
ٹکراؤ اور پہلے چلنے والی تلاش
دو مختلف رینجیں ٹکرا سکتی ہیں، اور دونوں ناکامیاں برے قاعدے کی بجائے ٹوٹے ٹنل جیسی دکھتی ہیں۔ آپ کا ایجاد کردہ عرف پورے راستے میں غیر استعمال شدہ ہونا چاہیے، اور اصل دور والی رینج آپ کے نیٹ ورک پر پہلے سے موجود نہیں ہونی چاہیے۔ تکرار وقفے وقفے سے غلط ہوسٹ کی طرف ٹریفک پیدا کرتی ہے، جس کی تشخیص مسترد کنکشن سے زیادہ مشکل ہے۔ قاعدہ شامل کرنے سے پہلے روٹنگ جدول سے پوچھیں۔
گیٹ وے پر، ip route get 192.168.2.17 کو ٹنل ڈیوائس کا نام بتانا چاہیے؛ مقامی bridge کا مطلب ہے کہ دور والی رینج ڈھکی ہوئی ہے اور کوئی nat قاعدہ اسے درست نہیں کرے گا۔ اگر آپ کا نیٹ ورک پہلے ہی 192.168.2.0/24 استعمال کرتا ہے، تو ٹکراؤ پر میپنگ ڈھیر کرنے کی بجائے دور والی سائٹ کو دوبارہ نمبر دیں۔
اصل کلائنٹ سے جانچ، پھر محفوظ رکھنا
اس مشین سے جانچ کریں جو عرف واقعی استعمال کرے گی، گیٹ وے سے نہیں، کیونکہ مقامی طور پر پیدا ہونے والا ٹریفک PREROUTING سے کبھی اسی طرح نہیں گزرتا۔ عرف والے ایک ہوسٹ سے کنکشن کھولیں اور کاؤنٹرز اور conntrack اندراج کو ساتھ ساتھ ظاہر ہوتے دیکھیں، پھر بند کریں اور تصدیق کریں کہ اندراج جاتا رہتا ہے۔ پرانا اندراج آدھے کھلے کنکشن کی طرف اشارہ کرتا ہے، جس کا عام مطلب ہے کہ جواب کبھی واپس نہیں آیا۔
curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17دو یا تین کامیاب کنکشن ریاضی کو ثابت کرتے ہیں، لیکن استحکام یا اگلے انجینئر کے بارے میں کچھ نہیں بتاتے۔ قواعد وہاں محفوظ کریں جہاں بوٹ عمل انہیں پڑھتا ہے، جو Debian اور Ubuntu پر iptables-save > /etc/iptables/rules.v4 netfilter-persistent فعال کر کے ہوتا ہے۔ ری بوٹ پر غائب ہونے والی میپنگ نہ ہونے سے بھی بدتر ہے، کیونکہ خلل بغیر کسی حالیہ تبدیلی کے آتا ہے جسے الزام دیا جا سکے۔
قواعد کے پاس ایک نوٹ چھوڑیں: عرفی رینج، اصل رینج، جوڑے کی وجہ اور کون سا جانب شروع کر سکتا ہے۔ وہ نوٹ ڈیزائن کو ان قواعد کے ڈھیر سے الگ کرتا ہے جنہیں کوئی مٹانے کی ہمت نہیں کرتا۔ یہ بعد کا سوال بھی حل کرتا ہے، جب دور والی سائٹ ہوسٹ شامل کرتی ہے اور کوئی غیر ترتیب شدہ پتہ پہلے ہی جواب دے رہا ہوتا ہے۔ اگر نوٹ کہے کہ دور والے جانب کو واپسی کا راستہ درکار ہے، تو اگلا شخص جانتا ہے کہ masquerade قاعدہ ہٹانا کنیکٹیویٹی توڑ دیتا ہے۔ یہاں دستاویزات سستی ہیں؛ رات تین بجے NAT انحصار دوبارہ دریافت کرنا نہیں۔