Cloud VPN به یک VM در GCP: از IP داخلی استفاده کنید، نه IP NAT
نقطه پایانی دروازه، نشانی داخلی 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 چگونه متفاوت است. یک IPv4 بیرونی در Compute Engine نگاشتی یک‌به‌یک روی تنها 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 حالت رایج است، نه تنها حالت، و استثناها هر یک قواعد خودشان را دارند.
محدوده‌های هم‌پوشان مسئله‌ای دیگرند
محدوده‌های خصوصی هم‌پوشان دلیل واقعی هستند که مردم به نشانی عمومی چنگ می‌زنند، و این اهرم نادرستی است. تغییر مقصد به نشانی NAT خود VM هم‌پوشانی را حل نمی‌کند؛ تغییر می‌دهد که بسته ادعا می‌کند برای کدام نشانی است، بی‌آنکه تعریف کند مسیر بازگشت چگونه کار می‌کند.
هم‌پوشانی را آگاهانه حل کنید: شماره‌گذاری را از نو انجام دهید، از یک طراحی ترجمهٔ پشتیبانی‌شده استفاده کنید، یا از شبکه‌ای مسیر بدهید که پیشوندها در آن برخورد نمی‌کنند. هر یک از این‌ها طراحی‌ای با مالک است. نشانی NAT طراحی نیست.
دو فیلد را جداگانه مستند کنید
همتای تونل و مقصد بار کاری را به‌عنوان دو فیلد جداگانهٔ رانبوک ثبت کنید، هر یک با مسیر و قاعدهٔ دیوار آتشی که آن را پشتیبانی می‌کند. تونل IPsecی که بالا می‌آید فقط می‌گوید طرف‌ها توافق دارند؛ هیچ چیزی دربارهٔ اینکه بار کاری روی کدام نشانی دسترسی‌پذیر است نمی‌گوید، و هیچ چیزی دربارهٔ اینکه آیا مسیر خصوصی‌اش کامل است.
با یک کارخواه واقعی در سوی دیگر بررسی کنید: نام را تفکیک کنید، تأیید کنید که نشانی داخلی را برمی‌گرداند، وصل شوید و ترافیک بازگشت را بررسی کنید. مستندات نشانی‌های IP در Compute Engine مرجع تمایز داخلی در برابر بیرونی است که در بالا به کار رفت.