فعال‌سازی ارسال IP روی یک دروازه GCE VPN موجود

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 معادل خودش را دارد، و کپی کردن یک فرمان sysctl لینوکسی در آن گام متناظر نیست.

از کلاینتی که به دسترسی نیاز دارد بررسی کنید

از یک کلاینت VPN به یک سرویس هدف آزمایش کنید، نه از خود دروازه. اتصالی که روی دروازه آغاز شود منبع متفاوتی دارد و هرگز قواعد ارسالی را که همین حالا فعال کردید تمرین نمی‌کند.

ویژگی را در هر چیزی که دستگاه را مدیریت می‌کند ثبت کنید. یک VM که دستی اصلاح شده تا زمانی کار می‌کند که جایگزینی بعدی آن بی‌صدا تنظیم اصلی را بازگرداند، و آن خرابی مانند یک بازگشت در نرم‌افزار VPN دیده می‌شود.

ترتیب کار: ویژگی را بخوانید، خط را صادر و ویرایش کنید، با NO_EFFECT اعتبارسنجی کنید، با REFRESH اعمال کنید، تأیید کنید که مهمان ارسال می‌کند، سپس از یک کلاینت آزمایش کنید.