چرا ماشین مجازی GCP شما نمی‌تواند به استخر IPv6 در OpenVPN پاسخ دهد

کلاینت VPN IPv6 شما به بار کاری می‌رسد، بار کاری به داخل تونل پاسخ می‌دهد و پاسخ هرگز نمی‌رسد. غریزه اول سرزنش فایروال یا تونل است و معمولاً هیچ‌کدام مقصر نیستند. نشانی‌ای که OpenVPN تخصیص می‌دهد یک شبکه داخلی است که فقط داخل تونل وجود دارد؛ Google Cloud هیچ ایده‌ای ندارد که fd42:90::/64 قرار است پشت یک ماشین مجازی خاص باشد تا زمانی که شما به آن بگویید.

دو سیستم جداگانه باید این واقعیت را بیاموزند و تنها یکی از آن‌ها OpenVPN است. VPC پیش از آنکه بتواند چیزی را بازگرداند به یک مسیر نیاز دارد و باید به ماشین مجازی اجازه داده شود آنچه می‌رسد را ارسال کند. اگر هر نیمه را اشتباه کنید، نشانه دقیقاً یکسان به نظر می‌رسد.

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

OpenVPN می‌تواند نشانی‌های IPv6 را از محدوده‌ای که انتخاب می‌کنید تخصیص دهد و آن محدوده ساختگی است که دو سر تونل بر آن توافق می‌کنند. این یک زیرشبکه Google Cloud نیست، در فهرست زیرشبکه‌های VPC ظاهر نمی‌شود و رابط شبکه ماشین مجازی آن نشانی‌ها را دریافت نمی‌کند. بنابراین بار کاری که به کلاینت پاسخ می‌دهد بسته‌ای به نشانی‌ای می‌فرستد که شبکه آن را غیرقابل مسیریابی می‌داند.

استخر را از هر محدوده‌ای که VPC پیش‌تر استفاده می‌کند بیرون نگه دارید. آن را از محدوده‌های پشت تونل‌های دیگرتان هم بیرون نگه دارید. همپوشانی یک خطای مسیریابی تمیز را به خطایی متناوب تبدیل می‌کند که فقط زیر بار دیده می‌شود.

نشانی‌دهی محلی یکتا مانند fd42:90::/64 انتخاب معقولی برای این شبکه داخلی است. پیشوند همچنین یادآوری می‌کند که طراحی به‌طور ذاتی خصوصی است. هیچ چیز در یک استخر ULA آن را به منبعی قانونی در اینترنت عمومی تبدیل نمی‌کند.

به VPC یک مقصد و یک گام بعدی بدهید

پاسخ به مسیری در VPC نیاز دارد که مقصدش استخر و گام بعدی‌اش ماشین مجازی VPN باشد. مستندات فعلی مسیرهای ایستا محدوده‌های مقصد IPv6 را پوشش می‌دهد و فهرست می‌کند کدام انواع گام بعدی واجد شرایط هستند، پس شکل پشتیبانی‌شده برای توپولوژی خود را بررسی کنید نه اینکه نمونه قدیمی IPv4 را کپی کنید.

نشانی گام بعدی باید نشانی‌ای باشد که واقعاً به رابط ابری نمونه اختصاص یافته است. نشانی داخلی تونل ماشین مجازی آن نشانی نیست. استفاده از آن به‌هرحال مسیری می‌سازد که پاک نصب می‌شود و هرگز با بسته‌ای مطابقت ندارد. پیش از نوشتن مسیر فهرست رابط‌ها را بخوانید.

اولویت مسیر به اندازه خود ورودی مهم است. مسیرهای زیرشبکه از مسیرهای سفارشی که اضافه می‌کنید مشخص‌تر هستند، بنابراین استخری که از محدوده زیرشبکه موجود بریده شده باشد، مهم نیست مسیر سفارشی چگونه نوشته شده، به مسیر زیرشبکه می‌بازد. یک استخر مجزا انتخاب کنید و سپس تأیید کنید که مسیر نمونه را به‌عنوان گام بعدی و پیشوند مقصد درست نشان می‌دهد:

gcloud compute routes create vpn6-return \
  --network=vpn-vpc \
  --destination-range=fd42:90::/64 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b

ارسال باید دو بار فعال شود

یک مسیر بسته را به نمونه تحویل می‌دهد. این کار نمونه را مایل نمی‌کند چیزی را که به آن نشانی نشده ارسال کند و این اجازه در دو لایه وجود دارد.

سمت ابر به قابلیت ارسال نمونه فعال نیاز دارد؛ این همان تنظیمی است که به ماشین مجازی اجازه می‌دهد ترافیک نشانی‌هایی را که مالک آن‌ها نیست دریافت و منتقل کند. سمت مهمان به ارسال IPv6 خودش نیاز دارد، چون هسته پس از رسیدن بسته تصمیم جداگانه‌ای می‌گیرد. هر دو باید روشن باشند پیش از آنکه یک پاسخ از تونل عبور کند.

sysctl -w net.ipv6.conf.all.forwarding=1

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

به OpenVPN بگویید چه کسی مالک چه چیزی است

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

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

خروج اینترنت را از این طراحی بیرون نگه دارید

دسترسی خصوصی و دسترسی اینترنت دو برنامه جداگانه هستند. یک استخر ULA می‌تواند پس از توافق مسیریابی و ارسال، از طریق تونل به بارهای کاری VPC برسد و همان استخر هیچ مسیری به اینترنت عمومی از طریق VPC ندارد، چون دروازه ابری منبع تونل دلبخواه را به‌عنوان منبع خود نمی‌پذیرد.

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