EC2 کا Elastic IP انسٹانس کا نجی VPN پتہ نہیں ہے

انسٹانس کا ایک نجی پتہ ہے، Elastic IP اس سے منسلک ہے، اور اس عوامی /32 کے لیے ایک راستہ VPN میں شامل کیا جاتا ہے اس امید پر کہ دونوں ایک ہی چیز بن جائیں گے۔ بنتے نہیں۔ Elastic IP ایک ترجمہ ہے جو مہمان کے باہر، انٹرنیٹ گیٹ وے کی طرف سے، اس ٹریفک پر کیا جاتا ہے جو انٹرنیٹ راستہ اختیار کرتی ہے۔ مہمان کا آپریٹنگ سسٹم وہ پتہ کبھی کسی انٹرفیس پر ترتیب دیا ہوا نہیں دیکھتا۔ اسے ٹنل انٹرفیس میں شامل کرنا اوپر کا ترجمہ دوبارہ پیدا نہیں کرتا اور اسی مشین کے لیے دوسری، متضاد شناخت بناتا ہے۔

دو پتے، ایک انسٹانس

انسٹانس کا نیٹ ورک انٹرفیس VPC کے اندر نجی پتہ رکھتا ہے، اور یہی وہ پتہ ہے جو مہمان جانتا ہے۔ Elastic IP اسی انٹرفیس سے منسلک ہے مگر نقشے کے عوامی جانب رہتا ہے۔

انٹرنیٹ کے ذریعے انسٹانس تک پہنچنے والی ہر چیز نجی پتے پر ترجمہ شدہ آتی ہے۔ انسٹانس انٹرنیٹ کو بھیجتی ہر چیز Elastic IP کو ماخذ بنا کر نکلتی ہے، پھر اسی ترجمے کی وجہ سے۔

مہمان کے اندر ایک پتہ موجود ہے۔ باہر دو ہیں۔ یہی عدم توازن اس شعبے کی بیشتر الجھن کی وضاحت کرتا ہے۔ مہمان یہ ترتیب نہیں دے سکتا کہ گیٹ وے کیا ترجمہ کرتا ہے۔ یہ صرف اسی پتے پر جواب دے سکتا ہے جو واقعی اس کے پاس ہے۔

انٹرنیٹ گیٹ وے واقعی کیا کرتا ہے

AWS کی انٹرنیٹ گیٹ وے دستاویز اس ترتیب کی وضاحت کرتی ہے: انسٹانس اپنے نجی IPv4 پتے سے واقف ہے، اور گیٹ وے انٹرنیٹ راستے کی ٹریفک کے لیے متعلقہ عوامی IPv4 یا Elastic IP ترجمہ فراہم کرتا ہے۔

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

اسی لیے عوامی /32 پر نشانہ بنایا گیا نجی VPN پیکٹ مہمان کے مقامی پتے کی طرف جانے والے نجی پیکٹ کے طور پر دوبارہ تفسیر نہیں ہوتا۔ پیکٹ اسی راستے کی پیروی کرتا ہے جس سے وہ میل کھاتا ہے، جو اسے انٹرنیٹ گیٹ وے کی طرف بھیجتا ہے، اور گیٹ وے کا رویہ اس پر منحصر ہے کہ راستہ دونوں سمتوں میں اجازت یافتہ ہے یا نہیں۔

ٹنل انٹرفیس کی چال کیوں ناکام ہوتی ہے

Elastic IP کو ٹنل انٹرفیس پر تفویض کرنا مہمان سے کہتا ہے کہ عوامی پتے کو مقامی سمجھے۔ اب دو چیزیں ایک ہی پتے کا دعویٰ کرتی ہیں: انٹرنیٹ راستے پر گیٹ وے کا ترجمہ اور ٹنل کے اندر مقامی انٹرفیس۔ واپسی ٹریفک کے پاس اس بارے میں کوئی مستقل جواب نہیں کہ کون سا لاگو ہوتا ہے۔

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

پتہ کبھی مسئلہ نہیں تھا۔ راستے کا انتخاب تھا۔

تین مقاصد، تین ڈیزائن

اگر مقصد عوامی VPN اینڈ پوائنٹ ہے، Elastic IP درست ذریعہ ہے: دور دراز ساتھی انٹرنیٹ کے ذریعے اس سے جڑتے ہیں اور خفیہ کردہ منتقلی انسٹانس پر ختم ہوتی ہے۔ پھر اندرونی اطلاقی ٹریفک نجی پتہ استعمال کرتی ہے۔

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

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

اپنے منتخب کردہ راستے کی تصدیق کریں

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

عوامی رسائی کے لیے کلائنٹ کا انٹرنیٹ اخراج، عوامی داخلے کی راہنمائی اور اس کی سیکیورٹی پالیسی کی تصدیق کریں۔ کیا VPN کلائنٹ ٹنل کے ذریعے عوامی اینڈ پوائنٹ تک پہنچ سکتا ہے، یہ ٹنل کے اخراجی اور فائر وال قواعد پر منحصر ہے، Elastic IP تعلق پر نہیں۔

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