Elastic IP در EC2 نشانی VPN خصوصی نمونه نیست

نمونه یک نشانی خصوصی دارد، Elastic IP به آن مرتبط است، و مسیری برای آن /32 عمومی به VPN افزوده می‌شود به این امید که آن دو یکی شوند. نمی‌شوند. Elastic IP ترجمه‌ای است که بیرون از مهمان، توسط دروازهٔ اینترنت، روی ترافیکی انجام می‌شود که مسیر اینترنت را می‌پیماید. سیستم‌عامل مهمان هرگز آن نشانی را روی هیچ واسطی پیکربندی‌شده نمی‌بیند. افزودن آن به واسط تونل، ترجمهٔ بالادست را بازتولید نمی‌کند و هویتی دوم و متناقض برای همان ماشین می‌سازد.

دو نشانی، یک نمونه

واسط شبکهٔ نمونه نشانی خصوصی‌ای درون VPC دارد، و همان نشانی‌ای است که مهمان می‌شناسد. Elastic IP به همان واسط مرتبط است اما در سمت عمومی نگاشت زندگی می‌کند.

هر چیزی که از راه اینترنت به نمونه می‌رسد، ترجمه‌شده به نشانی خصوصی می‌رسد. هر چیزی که نمونه به اینترنت می‌فرستد، با Elastic IP به‌عنوان مبدأ خارج می‌شود، باز هم به‌خاطر همان ترجمه.

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

دروازهٔ اینترنت در واقع چه می‌کند

مستندات AWS دربارهٔ دروازهٔ اینترنت این ترتیب را توصیف می‌کند: نمونه از نشانی IPv4 خصوصی خود آگاه است و دروازه ترجمهٔ متناظر IPv4 عمومی یا Elastic IP را برای ترافیک مسیر اینترنت فراهم می‌کند.

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

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

چرا ترفند واسط تونل شکست می‌خورد

اختصاص Elastic IP به واسط تونل از مهمان می‌خواهد نشانی عمومی را محلی بداند. اکنون دو چیز مدعی همان نشانی‌اند: ترجمهٔ دروازه در مسیر اینترنت و واسط محلی درون تونل. ترافیک بازگشتی پاسخ سازگاری ندارد که کدام یک اعمال می‌شود.

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

مشکل هرگز نشانی نبود. انتخاب مسیر بود.

سه هدف، سه طراحی

اگر هدف نقطهٔ پایانی عمومی VPN است، Elastic IP ابزار درست است: همتایان راه دور از راه اینترنت به آن وصل می‌شوند و انتقال رمزنگاری‌شده روی نمونه پایان می‌یابد. سپس ترافیک درونی برنامه از نشانی خصوصی استفاده می‌کند.

اگر هدف دسترسی خصوصی به برنامه است، مقصد نشانی خصوصی یا نام DNS خصوصی‌ای است که به آن تفکیک می‌شود، و مسیر VPN، گروه امنیتی و مسیر بازگشت همه باید هم‌خوان باشند. Elastic IP اصلاً در آن طراحی ظاهر نمی‌شود.

اگر هدف هویت خروجی عمومی پایدار برای کاربران VPN است، آن یک طراحی NAT در سمت خروجی است، نه نشانی‌ای روی تونل کارخواه. سه هدف که شبیه هم به نظر می‌رسند سه نمودار متفاوت می‌سازند، و تنها یکی از آن‌ها گذاشتن Elastic IP در جایی تازه را در بر می‌گیرد.

مسیری را که برگزیدید بررسی کنید

برای دسترسی خصوصی، تأیید کنید که مسیر VPN پیشوند خصوصی را پوشش می‌دهد، جدول مسیرهای VPC ترافیک را به تونل بازمی‌گرداند، گروه امنیتی مبدأ کارخواه را مجاز می‌کند و دیوار آتش خود کارخواه پاسخ را مجاز می‌کند. سپس یک درخواست واقعی را به‌جای ping بیازمایید.

برای دسترسی عمومی، خروجی اینترنت کارخواه، مسیریابی ورودی عمومی و سیاست امنیتی آن را تأیید کنید. اینکه کارخواه VPN بتواند از راه تونل به نقطهٔ پایانی عمومی برسد به قواعد خروجی و دیوار آتش تونل بستگی دارد، نه به ارتباط Elastic IP.

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