Terraform میں GCP Classic VPN: ٹنل کو روٹ کی بنیاد پر بنائیں

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

افسانہ: ٹنل موڈ فیلڈ

کنسول کا لیبل ظاہر کرتا ہے کہ API منتخب کنندگان میں کیا دیکھتا ہے۔ وسیلے میں کچھ بھی روٹ کی بنیاد پر نہیں کہتا، اس لیے درست قدر پر سیٹ کرنے کو کچھ نہیں۔

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

یہاں روٹ کی بنیاد پر کا مطلب کیا ہے

Google Classic VPN کے روٹ کی بنیاد پر ٹنلوں کو پالیسی کی بنیاد پر ٹنل قرار دیتا ہے جن کا مقامی منتخب کنندہ 0.0.0.0/0 ہوتا ہے۔ صرف دور دراز کی حدیں نام دی جاتی ہیں، اور مقامی طرف کو کسی بھی پتے کی طرح سمجھا جاتا ہے۔ اسی لیے آپ کی ترتیب میں نشان موڈ نہیں، قدر ہے۔ دونوں منتخب کنندگان واضح طور پر لکھیں اور منصوبے کے نتائج میں پڑھیں:

local_traffic_selector  = ["0.0.0.0/0"]
remote_traffic_selector = ["10.20.0.0/16"]

اس اقتباس میں ساتھی کا سابقہ مثال ہے؛ شکل ہی اہم حصہ ہے۔

روٹ ایک الگ شے ہے

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

resource "google_compute_route" "office" {
  name                = "office-via-vpn"
  dest_range          = "10.20.0.0/16"
  network             = google_compute_network.vpc.name
  next_hop_vpn_tunnel = google_compute_vpn_tunnel.to_office.id
  priority            = 1000
}

روٹ اسی ماڈیول میں بنائیں جس میں ٹنل ہے، تاکہ دونوں جائزے میں الگ نہ ہوں۔

ساتھی پر منتخب کنندگان کی عکاسی کریں

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

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

مستقل پتے کو دو لاگو کرنے میں تقسیم کریں

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

اب دو لاگو کرنا ہر ریلیز میں ساتھی تبدیل کرنے سے سستا ہے۔

لیبل نہیں، گفت و شنید کی تصدیق کریں

لاگو کرنے کے بعد تین الگ حقائق جانچیں: ٹنل رابطہ قائم ہونے کی اطلاع دیتا ہے، روٹ مطلوبہ اگلی چھلانگ کے ساتھ موجود ہے، اور ساتھی بتاتا ہے کہ مرحلہ 1 اور مرحلہ 2 دونوں اوپر ہیں۔

ٹنل اوپر اور مرحلہ 2 نیچے ہونے کا مطلب ہے کہ دونوں فریق منتخب کنندگان پر متفق نہیں:

• ایک فریق ایسا ذیلی نیٹ ورک فہرست کرتا ہے جو دوسرا نہیں کرتا۔
• ایک فریق ایسا مجموعہ استعمال کرتا ہے جو دوسرے نے تنگ کیا ہے۔
• روٹ موجود ہے مگر کسی دوسرے ٹنل کی طرف اشارہ کرتا ہے۔

Classic VPN ایک ہی ٹنل ہے جس کا SLA HA VPN سے کم ہے، اور HA VPN دو انٹرفیس، دو ٹنل اور مختلف وسیلہ اقسام کے ساتھ BGP استعمال کرتا ہے۔ کسی کلاسیکی مثال کو HA ترتیب میں نقل کرنا اور یہ توقع کرنا کہ منتخب کنندہ فیلڈ اسی طرح برتاؤ کریں گے، ایک الگ غلطی ہے جس سے بچنا چاہیے۔ ٹنل کے فیلڈ خود google_compute_vpn_tunnel حوالے میں۔