GCP VM تک Cloud VPN: NAT IP نہیں، اندرونی IP استعمال کریں
گیٹ وے کا آخری نقطہ، VM کا اندرونی پتہ اور بیرونی ایک سے ایک NAT پتہ تین مختلف کام کرتے ہیں۔ دیکھیں کہ آپ کا راستہ کون سا استعمال کرتا ہے۔
جب کوئی مقامی نیٹ ورک Cloud VPN کے ذریعے VPC تک پہنچتا ہے، تو Compute Engine سروس کے لیے منزل عام طور پر VM کا اندرونی پتہ ہوتا ہے۔ بیرونی IPv4 پتہ کوئی دوسرا پتہ نہیں ہے جسے آپ اسی نجی راستے میں رکھ سکیں۔ اس شعبے میں زیادہ تر الجھن اس بات سے آتی ہے کہ تین کاموں والے تین پتوں کو ایک دوسرے کی جگہ استعمال ہونے والا سمجھا جاتا ہے، اس لیے پہلے یہ نام دیں کہ کوئی دیا ہوا پیکٹ کون سا استعمال کر رہا ہے۔
تین پتے، تین کام
ان میں سے کسی کو بھی ڈی بگ کرنے سے پہلے تینوں کے نام بتا دیں، کیونکہ جواب بدل دیتا ہے کہ آگے آپ کون سی چیز دیکھیں گے۔
| Address | Job |
|---|---|
| Cloud VPN endpoint | where the IPsec peers meet |
| Internal IP | the address your route and firewall must name |
| External IPv4 | the platform's inbound mapping, not a guest address |
پہلا سرنگ کا ہے۔ دوسرا آپ کے راستے اور فائروال ڈیزائن کا ہے۔ تیسرا آنے والی انٹرنیٹ رسائی کا ہے اور وہ نقشہ بنایا جاتا ہے، جوڑا نہیں جاتا۔ ان میں سے کسی ایک کے لیے کام کرنے والا ڈیزائن باقی دو کے بارے میں کچھ نہیں کہتا۔
بیرونی پتہ دوسرا انٹرفیس کیوں نہیں
Compute Engine پر اندرونی اور بیرونی رسائی کیسے مختلف ہیں اس کے لیے پتوں کی رہنمائی ہی مستند ماخذ ہے۔ Compute Engine کا بیرونی IPv4 انسٹانس کے واحد اندرونی NIC پر ایک سے ایک نقشہ سازی ہے، اس لیے مہمان کو اس NIC پر کبھی دوسرا انٹرفیس یا دوسرا پتہ نظر نہیں آتا۔ VM اندر سے جو رپورٹ کرتا ہے وہ اب بھی ایک بنیادی اندرونی پتہ ہے۔
اسی لیے نجی کلائنٹ سرنگ کے ذریعے 10.24.1.7 کی طرف راستہ بناتا ہے، اور VM کے بیرونی پتے کو نشانہ بنانے والا کلائنٹ مختلف راستوں پر ہوتے ہیں۔ عوامی پتے کے لیے فائروال قاعدہ کھولنے سے اس VPC راستے میں کچھ نہیں بدلتا جسے سرنگ کی ٹریفک لے کر جانا ہے، اور مہمان کا راستہ تبدیل کرنے سے پلیٹ فارم کی نقشہ سازی نہیں ہلتی۔ وہ پتہ چنیں جس کا نام آپ کا راستہ لیتا ہے، پھر صرف انہی چیزوں کی جانچ کریں جو اسے کنٹرول کرتی ہیں۔ یہ نظم اس ٹربل شوٹنگ راستے سے زیادہ تر اندازے ہٹا دیتی ہے۔
gcloud کے ساتھ راستہ چلیں
انسٹانس سے شروع کریں اور دونوں پتے اسی چیز سے پڑھیں، تاکہ آپ جان سکیں کہ آپ کی دستاویز کس کے بارے میں بات کر رہی ہے:
gcloud compute instances describe app-1 --zone=europe-west1-b \
--format="value(networkInterfaces[0].networkIP,networkInterfaces[0].accessConfigs[0].natIP)"پھر اس روٹنگ اور اجازت کی تصدیق کریں جن پر راستہ واقعی منحصر ہے:
gcloud compute routes list --filter="destRange:10.24.1.0/24"
gcloud compute firewall-rules list --filter="sourceRanges:10.99.0.0/24"
gcloud compute vpn-tunnels describe TUNNEL_NAME --region=europe-west1سرنگ کے اعلان کردہ اور سیکھے گئے دائرے پڑھیں, ورک لوڈ سب نیٹ کے لیے VPC راستہ، اور وہ فائروال قاعدہ جو مقامی ماخذ کو اجازت دیتا ہے۔ مہمان پر موجود سامع کے متعلقہ ہونے سے پہلے یہ تینوں مطابقت رکھنے چاہئیں۔
پھر مہمان کی جانچ کریں: کیا سروس اندرونی پتے پر سن رہی ہے، اور کیا اس کا واپسی راستہ دوبارہ VPC سے گزرتا ہے؟ صرف عوامی پتے سے بندھا سامع اس امتحان میں ناکام ہوگا، چاہے کلاؤڈ کی طرف کی ہر چیز درست ہو۔
عوامی سابقہ ایک اور سوال ہے
اوپر کی کوئی بات یہ نہیں کہتی کہ VPN کے اندر لے جایا جانے والا ہر پتہ RFC1918 ہی ہونا چاہیے۔ دور دراز کا نیٹ ورک عوامی فضا سے قانونی طور پر نمبر دیا جا سکتا ہے، بشرطے کہ پلیٹ فارم روٹنگ کی حمایت کرے اور آپریٹر کے پاس پتے کا اختیار ہو۔ یہ ایک عام ڈیزائن انتخاب ہے۔
یہ کسی عام بیرونی NAT پتے کو دوسرے اندرونی سب نیٹ پتے کی طرح سمجھنے کے برابر نہیں ہے۔ ایک سابقہ ہے جسے آپ روٹ کرتے ہیں؛ دوسرا نقشہ سازی ہے جو پلیٹ فارم آنے والی رسائی پر لاگو کرتا ہے۔
بیرونی IPv6 اور خاص طور پر بنائے گئے پتہ انتظامات کا اپنا معنی ہے۔ اگر آپ کا منصوبہ ان میں سے کسی پر منحصر ہے، تو IPv4 کی صورت سے عمومیت اختیار کرنے کے بجائے اس خصوصیت کے لیے پلیٹ فارم دستاویز پڑھیں۔ IPv4 نقشہ سازی عام صورت ہے، واحد نہیں، اور ہر استثنا کے اپنے قواعد ہیں۔
ملی ہوئی حدود ایک اور مسئلہ ہیں
ملی ہوئی نجی حدود ایک حقیقی وجہ ہیں جس سے لوگ عوامی پتے کی طرف جاتے ہیں، اور یہ غلط ذریعہ ہے۔ منزل کو VM کے NAT پتے میں بدلنا میلان حل نہیں کرتا؛ یہ بدلتا ہے کہ پیکٹ کس پتے کے لیے ہونے کا دعوی کرتا ہے، واپسی راستہ کیسے کام کرتا ہے اس کی وضاحت کے بغیر۔
میلان کو دانستہ حل کریں: دوبارہ نمبر دیں، معاون ترجمہ ڈیزائن استعمال کریں، یا ایسے نیٹ ورک سے راستہ بنائیں جہاں سابقے ٹکراتے نہیں۔ ان میں سے ہر ایک مالک والا ڈیزائن ہے۔ NAT پتہ کوئی ڈیزائن نہیں ہے۔
دونوں فیلڈ الگ الگ دستاویز کریں
سرنگ کے ساتھی اور ورک لوڈ کی منزل کو دو الگ رن بک فیلڈ کے طور پر درج کریں، ہر ایک کے ساتھ وہ راستہ اور فائروال قاعدہ جو اس کی حمایت کرتا ہے۔ اوپر آنے والی IPsec سرنگ صرف یہ بتاتی ہے کہ فریقین متفق ہیں؛ یہ نہیں بتاتی کہ ورک لوڈ کس پتے پر قابل رسائی ہے، اور نہ یہ کہ اس کا نجی راستہ مکمل ہے یا نہیں۔
دوسری طرف ایک حقیقی کلائنٹ سے تصدیق کریں: نام حل کریں، تصدیق کریں کہ وہ اندرونی پتہ واپس دیتا ہے، جڑیں، اور واپسی ٹریفک جانچیں۔ Compute Engine IP پتہ دستاویز اوپر استعمال شدہ اندرونی بمقابلہ بیرونی فرق کا حوالہ ہے۔