NAT کے پیچھے OpenVPN کلائنٹ کیسے انٹرنیٹ ایگزٹ بنتا ہے

تین Linux ہوسٹ، ایک ڈیزائن: عوامی طور پر قابلِ رسائی OpenVPN ہب، ایک لیپ ٹاپ اور اندر کچھ بھی آگے نہ بھیجنے والے عام گھریلو راؤٹر کے پیچھے بیٹھی ایگزٹ مشین۔ ایگزٹ خود ہب کو کال کرتا ہے۔ پھر صارف کا انٹرنیٹ ٹریفک لیپ ٹاپ پر ٹنل میں داخل ہوتا ہے اور ایگزٹ کے اپنے اپ لنک سے باہر نکلتا ہے۔ اس ترتیب میں حیران کن ہر بات ایک تفصیل سے آتی ہے: کنکشن ایگزٹ نے شروع کیا، اس لیے اندر کا راستہ پہلے ہی موجود ہے اور اسے بنانے کے لیے پورٹ فارورڈنگ کی ضرورت نہیں۔

آگے کنفیگریشن کی ترتیب نہیں بلکہ پیکٹ کا راستہ دیکھا گیا ہے، کیونکہ کنفیگریشن تبھی معنی رکھتی ہے جب معلوم ہو کہ کون سا جزو کون سا فیصلہ کرتا ہے۔ ہر پرت ٹھیک ایک فیصلہ کرتی ہے، اور غلطیاں وہاں جمع ہوتی ہیں جہاں دو پرتوں کو ایک سمجھا جائے۔

دو ٹرانسپورٹ سیشن، ایک اندرونی راستہ

ہر ہوسٹ ہب سے اپنا الگ بیرونی کنکشن رکھتا ہے، اور ان میں سے کوئی دوسرے کے بارے میں نہیں جانتا۔ صارف کا انٹرنیٹ کی طرف ٹریفک ایک الگ اندرونی بہاؤ ہے، جو صارف کی ٹنل کے اندر لے جایا جاتا ہے اور پھر ایگزٹ کی ٹنل سے دوبارہ باہر بھیجا جاتا ہے۔ ہب کو یہی اندرونی بہاؤ روٹ کرنا ہے، اور ایگزٹ کو یہی آگے بھیجنا ہے۔

outer: consumer --TLS--> hub
outer: exit     --TLS--> hub
inner: consumer --tun--> hub --internal--> exit --tun--> uplink

چونکہ دونوں بیرونی کنکشن کلائنٹ کی طرف سے باہر جاتے ہیں، ایگزٹ کا راؤٹر کبھی اِن باؤنڈ SYN نہیں دیکھتا اور اسے کبھی ڈیسٹینیشن NAT قاعدے کی ضرورت نہیں پڑتی۔ اسے صرف قائم شدہ ٹرانسپورٹ کو زندہ رکھنا ہے، جو وہ کسی بھی طویل کنکشن کے لیے پہلے ہی کرتا ہے۔ عوامی انٹرنیٹ پر کسی چیز کو پہلے ایگزٹ تک پہنچنے کی ضرورت نہیں، اسی لیے اس اپ لنک پر متحرک پتہ کوئی مسئلہ نہیں۔ راؤٹر کو پھر بھی باہر جانے والے سیشن کی اجازت دینی ہوتی ہے، لیکن یہ وہی اجازت ہے جو براؤزر پہلے ہی استعمال کرتا ہے۔

iroute سرور کے اندر واقعی کیا نصب کرتا ہے

ہب ہی واحد آلہ ہے جو طے کرتا ہے کہ کون سا ساتھی کس منزل کا مالک ہے، اور یہ فیصلہ وہ کرنل میں نہیں بلکہ اپنی یوزر اسپیس راؤٹنگ ٹیبل میں کرتا ہے۔ ایگزٹ کے لیے exit-node نامی client-config-dir اندراج وہاں طے شدہ سابقہ کا دعویٰ کر سکتا ہے:

# /etc/openvpn/server/ccd/exit-node
iroute 0.0.0.0 0.0.0.0

وہ سطر سرور پروسیس کو بتاتی ہے "کسی بھی منزل والے اندرونی پیکٹ اس کلائنٹ کے ہیں"۔ یہ ہب کے آپریٹنگ سسٹم میں طے شدہ راستہ نہیں جوڑتی اور ہب کو انٹرنیٹ گیٹ وے بھی نہیں بناتی۔ OpenVPN 2.6 حوالہ کلائنٹ کے لیے مخصوص اندرونی راؤٹنگ اور کرنل راؤٹنگ کو الگ طریقوں کے طور پر رکھتا ہے، اور یہی علیحدگی وجہ ہے کہ یہ ڈیزائن ہب کے طے شدہ راستے کو چھوئے بغیر کام کرتا ہے۔

صارف کو آئینے جیسی ہدایت چاہیے، push کے طور پر پہنچائی گئی، تاکہ اس کا اپنا ٹریفک مقامی گیٹ وے سے باہر جانے کے بجائے ٹنل میں داخل ہو۔ سب نیٹ ٹوپولوجی میں پول ایگزٹ کے tun آلے پر منسلک راستہ ہے، اس لیے واپسی کی سمت کو کوئی اضافی push درکار نہیں؛ ایگزٹ کو جو نہیں ملنا چاہیے وہ نیچے دیا گیا ری ڈائریکشن ہے، جو اس کے اپنے اپ لنک ٹریفک کو اسی ٹنل میں واپس بھیج دے گا جسے وہ استعمال کرنا چاہتا ہے۔ اسے صرف صارف کو بھیجیں اور CCD فائل کے منتخب ہونے پر بھروسہ کرنے کے بجائے کلائنٹ پر لاگو راستے پڑھیں۔

# /etc/openvpn/server/ccd/consumer-01
push "redirect-gateway def1"

آگے بھیجنے کا کام ایگزٹ کا کرنل کرتا ہے

ایگزٹ کے اندر صارف کا پیکٹ tun انٹرفیس پر کسی انٹرنیٹ ہوسٹ کے پتے پر آتا ہے۔ کرنل اپنا راؤٹنگ ٹیبل دیکھتا ہے، بہترین مطابقت کے طور پر اصل اپ لنک تلاش کرتا ہے اور پھر دو آزاد پالیسیاں لاگو کرتا ہے: کیا یہ پیکٹ بالکل آگے بھیجا جا سکتا ہے، اور کیا یہ اس انٹرفیس سے اس ماخذ پتے کے ساتھ نکل سکتا ہے۔ آگے بھیجنا ایک sysctl ہے، اور بہت سی تقسیموں میں طے شدہ طور پر بند ہوتا ہے۔

اس لیے ایگزٹ کو مسلسل چالو IPv4 آگے بھیجنا، صارف کے ٹنل ماخذوں کو اپ لنک کی طرف قبول کرنے والا قاعدہ اور tun کے ذریعے واپس آنے والا جوابی راستہ درکار ہے۔ پورے ہوسٹ کے لیے آگے بھیجنا چالو کرنا اس کے ذریعے روٹ ہونے والی ہر دوسری چیز کا رویہ بھی بدلتا ہے، اس لیے قاعدے کو سب کچھ قبول کرنے کے بجائے ماخذ اور انٹرفیس کے نام بتانے چاہئیں۔

واپسی کا راستہ ماخذ کی ترجمہ خریدتا ہے

انٹرنیٹ ہوسٹ کے پاس 10.90.0.x پتے تک کوئی راستہ نہیں، اس لیے جواب ایگزٹ تک پہنچنے سے پہلے ہی مسترد ہو جاتے۔ پیکٹ کے اپ لنک چھوڑتے وقت ماخذ دوبارہ لکھنا اسے حل کرتا ہے، اور کنکشن ٹریکنگ واپسی پر اس دوبارہ لکھائی کو الٹ دیتی ہے۔

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o enp1s0 -j MASQUERADE
ip -4 route get 10.90.0.9   # run on the exit: must point at the tun

اوپر دیا گیا قاعدہ ایک اپ لنک انٹرفیس کے لیے نقطۂ آغاز ہے، فائر وال پالیسی نہیں۔ ماخذ کو انہی تفویضات تک محدود کریں جنہیں آپ نے واقعی اجازت دی، اور ایگزٹ کی اپنی اِن پٹ پالیسی الگ رکھیں تاکہ ٹنل ٹریفک کے لیے ماسکریڈنگ مقامی سروسز کو خاموشی سے بے نقاب نہ کرے۔ متحرک اپ لنک پتے والے ہوسٹ پر ماسکریڈ آپ کو پتہ ہاتھ سے ٹریک کرنے سے بھی بچاتا ہے۔

ہب کہاں نافذ کر سکتا ہے اور کہاں نہیں

client-to-client اور روایتی یوزر اسپیس ڈیٹا پاتھ کے ساتھ ہب سرور پروسیس کے اندر ہی ساتھیوں کے درمیان اندرونی پیکٹ حوالے کرتا ہے۔ وہ کبھی ہب کے کرنل FORWARD چین سے نہیں گزرتے، اس لیے وہاں کا کرنل قاعدہ کتنی ہی احتیاط سے لکھا ہو، ساتھیوں کے درمیان گزر کو محدود نہیں کر سکتا۔ نفاذ سرور کی اپنی پالیسی میں ہی ہونا چاہیے: کسے جڑنے کی اجازت ہے، اسے کون سی CCD فائل ملتی ہے اور ایگزٹ کی طے شدہ ملکیت بالکل دی جاتی ہے یا نہیں۔

اسی لیے طے شدہ iroute وسیع اعتماد کا فیصلہ ہے۔ ایگزٹ کو من مانی انٹرنیٹ پتوں سے واپسی ٹریفک قانونی طور پر قبول کرنا ہوتا ہے، اور یہ ایسی مشین ہونی چاہیے جسے آپ کنٹرول، پیچ اور نگرانی کرتے ہیں۔ وہی ملکیت ایسے ساتھی کو دینا جسے آپ راؤٹر نہ سونپیں وہی غلطی ہے جس کی یہ ڈیزائن دعوت دیتا ہے۔

رکنیت ہی اصل کنٹرول ہے۔ جو بھی کلائنٹ اپنے راستے ترتیب دے سکتا ہے وہ ایگزٹ استعمال کرنے کی کوشش کر سکتا ہے، اس لیے یہ محدود کرنا کہ کون جڑ سکتا ہے یا ایگزٹ کس ساتھیوں کی خدمت کرے گا، ڈیزائن کا حصہ ہے، بعد کا خیال نہیں۔

ایگزٹ کے غائب ہونے پر محفوظ طریقے سے ناکام ہونا

ایگزٹ کو آف لائن کریں اور اندرونی طے شدہ ملکیت اس کے سیشن کے ساتھ غائب ہو جاتی ہے۔ جو نہیں ہونا چاہیے وہ یہ ہے کہ ہب خاموشی سے متبادل ایگزٹ بن جائے: VPN پول سے ہب کے اپ لنک تک کوئی طے شدہ راستہ نہ ہو، اور ہب پر کوئی وسیع ماسکریڈ قاعدہ نہ ہو جو وہی ٹریفک خوشی سے آگے بھیج دے۔ اس ناکامی کو جان بوجھ کر جانچیں، پھر پہلے سے کھلے صفحے کے بجائے نئے بہاؤ سے بحالی جانچیں۔

# on the consumer, with the exit up and then down
ip -4 route get 1.1.1.1
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

اگر ایگزٹ جانے کے بعد بھی صارف کا ٹریفک انٹرنیٹ تک پہنچتا ہے تو کوئی اور چیز اسے لے جا رہی ہے اور آپ کی مقصود حد موجود نہیں۔ DNS اور IPv6 کو بھی الگ فیصلے سمجھیں: IPv4 راستہ اور ماسکریڈ AAAA ٹریفک کے بارے میں کچھ نہیں کہتے، اور ہب کی طرف سے بھیجا گیا ری زولور وہیں سے جواب دے گا جہاں سے استفسار واقعی نکلتا ہے۔