Classic VPN در Terraform: تونل را مسیرمحور کنید

در Classic VPN برچسب رفتار را تعیین نمی‌کند. مسیرمحور یعنی انتخابگر محلی 0.0.0.0/0، انتخابگرهای راه دور منطبق و یک مسیر صریح.

طرح به‌درستی اعمال می‌شود، تونل بالا می‌آید و کنسول آن را سیاست‌محور می‌نامد. ترافیک هنوز عبور نمی‌کند و جست‌وجوی کلید مسیرمحور در منبع 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 را که انتظار دارید استفاده کنید پوشش دهد. اگر هر طرف محدود شود، فاز 2 شکست می‌خورد حتی اگر فاز 1 موفق شود. این رایج‌ترین شکل پیکربندی است که در کنسول درست به نظر می‌رسد و هیچ ترافیکی حمل نمی‌کند.

در بازبینی تغییر، انتخابگرهای دو طرف را کنار هم چاپ کنید.

آدرس ثابت را به دو اعمال تقسیم کنید

ساخت آدرس رزروشده و تونلی که به آن ارجاع می‌دهد در یک اعمال، منبع شناخته‌شده‌ای برای نوسان است، چون آدرس باید پیش از آنکه قاعده ارسال بتواند از آن استفاده کند وجود داشته باشد. ابتدا فقط منبع آدرس را اعمال کنید، سپس دروازه، قواعد ارسال و تونل را اضافه کنید و دوباره اعمال کنید. Terraform در اجرای دوم آدرس موجود را از وضعیت می‌خواند و دوباره استفاده می‌کند. اگر آن را نادیده بگیرید، تونل ممکن است در هر اعمال آدرس عمومی تازه بگیرد و این هر بار پیکربندی همتا را می‌شکند.

دو اعمال اکنون از تغییر همتا در هر انتشار ارزان‌تر است.

مذاکره را بررسی کنید، نه برچسب را

پس از اعمال، سه واقعیت جداگانه را بررسی کنید: تونل اتصال برقرار را گزارش می‌کند، مسیر با گام بعدی مورد نظر وجود دارد و همتا گزارش می‌کند که هر دو فاز 1 و 2 بالا هستند.

تونلی که بالا است ولی فاز 2 پایین، یعنی دو طرف درباره انتخابگرها توافق ندارند:

  • یک طرف زیرشبکه‌ای را فهرست می‌کند که طرف دیگر فهرست نمی‌کند.
  • یک طرف تجمیعی را به کار می‌برد که طرف دیگر محدود کرده است.
  • مسیر وجود دارد اما به تونل دیگری اشاره می‌کند.

Classic VPN یک تونل واحد با SLA پایین‌تر از HA VPN است و HA VPN از دو رابط، دو تونل و BGP با انواع منابع متفاوت استفاده می‌کند. کپی کردن یک نمونه کلاسیک در پیکربندی HA و انتظار اینکه فیلدهای انتخابگر همان‌طور رفتار کنند خطای جداگانه‌ای است که ارزش اجتناب دارد. خود فیلدهای تونل در مرجع google_compute_vpn_tunnel.

مقالات مرتبط