ایک AWS Client VPN سیشن کے پیچھے LAN: کیا آگے بھیجا جاتا ہے

لیپ ٹاپ AWS Client VPN اینڈ پوائنٹ سے جڑتا ہے، نجی ذیلی نیٹ تک پہنچتا ہے، اور سب کچھ ٹھیک لگتا ہے۔ اسی LAN کا ڈیسک ٹاپ کہیں نہیں پہنچتا، حالانکہ Linux میزبان میں بھی برج انٹرفیس ہے اور دونوں مشینیں ایک ہی تار پر ہیں۔ ٹنل میں کچھ بھی غلط کنفیگر نہیں ہے؛ جو حصہ غائب ہے وہ روٹنگ ہے، اور برج ایک گمراہ کن سراغ ہے۔

Client VPN سیشن کو LAN تک بڑھانا گیٹ وے کا کردار ہے۔ یہ کسی منظم سروس میں کھینچا گیا Ethernet حصہ نہیں ہے۔

میزبان چلتا ہے اور LAN نہیں

Linux مشین پر ٹنل انٹرفیس کا پتہ Client VPN کلائنٹ CIDR کے اندر ہے، اور اینڈ پوائنٹ نے VPC رینجز کے لیے راستے بھیجے ہیں۔ اس مشین پر کی گئی درخواست مقامی طور پر بنایا گیا ٹریفک ہے: یہ راستہ چنتا ہے، ٹنل سے باہر جاتا ہے اور جواب پاتا ہے۔ وہ راستہ کبھی فارورڈنگ کوڈ، LAN انٹرفیس یا ٹرانزٹ کو کنٹرول کرنے والے کسی فائر وال اصول کو نہیں چھوتا۔

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

ہر کلائنٹ گیٹ وے نہیں بن سکتا

AWS بتاتا ہے کہ اس کا Client VPN ڈیسک ٹاپ ایپ IP فارورڈنگ کی حمایت نہیں کرتا، اور دیگر کلائنٹ کر سکتے ہیں۔ یہ پابندی کسی بھی کمانڈ ٹائپ کرنے سے پہلے آرکیٹیکچر طے کرتی ہے۔ اگر دستیاب واحد کلائنٹ سرکاری ڈیسک ٹاپ ایپ ہے، تو LAN کے لیے فارورڈ کرنے والا Linux گیٹ وے ایسی ترتیب نہیں جسے آپ مکمل کر سکیں، اور کتنی ہی masquerading اسے نہیں بدلے گی۔

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

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

LAN کو ٹنل کی طرف موڑیں اور اس کا ترجمہ کریں

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

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

اصول کو اوپر کی طرح ٹنل انٹرفیس اور VPC رینج تک محدود رکھیں، میزبان جو کچھ فارورڈ کرتا ہے اس سب کو masquerade کرنے کے بجائے۔ تنگ اصول پر سوچنا آسان ہے، اور یہ اس ٹریفک کو خاموشی سے نہیں بدلتا جسے اپنا اصل ماخذ پتہ رکھنا تھا۔

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

جواب کو بھی راستہ چاہیے

درخواست کے VPC تک پہنچنے کے بعد، جواب کو انہی ترجمہ حالتوں سے واپس آ کر گیٹ وے پر LAN راستہ تلاش کرنا ہوگا۔ وہ حصہ عام طور پر اس وقت کام کرتا ہے جب masquerade اصول موجود ہو، کیونکہ نقشہ سازی اسی میزبان پر رہتی ہے جس نے اسے کیا۔ یہ اس وقت ٹوٹتا ہے جب VPC کی طرف ایسا راستہ ہو جو جواب کہیں اور بھیجے، اور اسی لیے کلائنٹ CIDR راستہ اور اینڈ پوائنٹ پر ذیلی نیٹ کا ربط دونوں اہم ہیں۔

صرف ping نہیں، کاؤنٹر دیکھیں۔ صفر پیکٹ والا masquerade اصول آپ کو بتاتا ہے کہ درخواست کبھی ٹنل انٹرفیس تک نہیں پہنچی، جو LAN راستے یا کلائنٹ کی اپنی روٹنگ جدول کی طرف اشارہ کرتا ہے۔ پیکٹ ہوں مگر جواب نہ ہوں ایسا اصول VPC کی طرف، اجازت کے اصولوں یا ایسے سیکیورٹی گروپ کی طرف اشارہ کرتا ہے جو ترجمہ شدہ ماخذ قبول نہیں کرتا۔ کچھ بھی بدلنے سے پہلے دونوں سمتوں کو پڑھیں، کیونکہ صرف ایک طرف بڑھتی گنتی سست راستہ نہیں بلکہ یک طرفہ راستہ ہے۔

یاد رکھیں کہ اینڈ پوائنٹ ایک منظم سروس ہے۔ ترمیم کے لیے کوئی سرور کنفیگریشن فائل نہیں اور شامل کرنے کے لیے کوئی client-config ہدایت نہیں، اس لیے حسب ضرورت کلائنٹ ذیلی نیٹ راستوں والے خود منتظم OpenVPN سرور کے لیے لکھی ہدایات منتقل نہیں ہوتیں۔ AWS میں لیور ذیلی نیٹ کا ربط، اجازت کے اصول اور VPC کی روٹنگ جدولیں ہیں۔

مشترکہ شناخت وہ حصہ ہے جس کا جواب پالیسی کو دینا ہے

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

یہ قابل قبول ہو سکتا ہے، یا یہی ڈیزائن کے مسترد ہونے کی وجہ ہو سکتا ہے۔ یہ اس پر منحصر ہے کہ VPC وسائل کس کے کال کرنے کے بارے میں کیا فرض کرتے ہیں۔ اجازت کے ماڈل میں فٹ ہونے والی مشترکہ شناخت ٹھیک ہے؛ جو خاموشی سے ایک مصدقہ سیشن کو پورے LAN کی رسائی میں بدل دے وہ لکھے جانے کا منتظر دریافت ہے۔

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

کلائنٹ، راستہ، ترجمہ اور شناخت کی کہانی اسی ترتیب سے طے کریں۔ ہر ایک اگلے کو محدود کرتا ہے، اور یہ ترتیب بتاتی ہے کہ میزبان کیوں چلتا ہے جبکہ LAN نہیں۔