موجودہ GCE VPN گیٹ وے پر IP فارورڈنگ فعال کریں

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

جھنڈا کیا اجازت دیتا ہے، اور کیا نہیں

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

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

موجودہ خصوصیت پڑھیں

کچھ بھی بدلنے سے پہلے ترتیب کا جائزہ لیں، مطلوبہ انسٹنس، پروجیکٹ اور زون کے خلاف صرف پڑھنے والا describe استعمال کرتے ہوئے:

gcloud compute instances describe VM_NAME --project PROJECT_ID --zone ZONE --format='value(canIpForward)'

false قدر صرف اسی صورت میں اہم ہے جب یہ VM اگلا ہاپ ہونا چاہیے۔ اگر ایسا ہے تو راستے کا باقی حصہ بھی الگ سے جانچنا ہوگا، کیونکہ خصوصیت طویل زنجیر میں ایک سطر ہے۔

موجودہ انسٹنس کو اپ ڈیٹ کریں

Google کی انسٹنس کی خصوصیات کی تجدید کاری کا طریقہ کار موجودہ وسیلہ برآمد کرتا ہے، خصوصیت بدلتا ہے اور نتیجہ جمع کرواتا ہے۔ یہ بنانے کے وقت کے --can-ip-forward جھنڈے سے مختلف ورک فلو ہے، اور چلتے ہوئے VM پر کام کرنے والا یہی ہے۔

پہلے تعریف کو مقامی فائل میں برآمد کریں، اور موازنہ کے لیے غیر تبدیل شدہ نقل رکھیں:

gcloud compute instances export VM_NAME --project PROJECT_ID --zone ZONE --destination=instance.yaml

اس برآمد شدہ فائل میں خصوصیت مقرر کریں اور اور کچھ نہ بدلیں:

canIpForward: true

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

کسی بھی مؤثر تبدیلی کی اجازت سے پہلے اپ ڈیٹ میکانزم سے فائل کی توثیق کرنے اور یہ بتانے کو کہیں کہ کیا درکار ہوگا:

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=NO_EFFECT

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

جائزہ شدہ فائل کو refresh کی حد کے ساتھ لاگو کریں:

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=REFRESH

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

مہمان کو اب بھی پیکٹ روٹ کرنا ہے

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

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

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

Linux گیٹ وے پر، کرنل فارورڈنگ مہمان کی ترتیب کا حصہ ہے۔ pfSense آلے کا اپنا مساوی ہے، اور اس میں Linux sysctl کمانڈ نقل کرنا موزوں مرحلہ نہیں۔

اس کلائنٹ سے توثیق کریں جسے رسائی درکار ہے

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

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

کام کی ترتیب: خصوصیت پڑھیں، ایک سطر برآمد اور تدوین کریں، NO_EFFECT سے توثیق کریں، REFRESH سے لاگو کریں، تصدیق کریں کہ مہمان فارورڈ کرتا ہے، پھر کسی کلائنٹ سے جانچیں۔