چرا EC2 به لپ‌تاپ شما در AWS Client VPN نمی‌رسد
Client VPN منابع IPv4 کارخواه را به رابط نقطه پایانی ترجمه می‌کند. به همین دلیل پاسخ کار می‌کند و اتصال تازه از EC2 نه.
لپ‌تاپی که از طریق AWS Client VPN متصل شده، بدون هیچ مشکلی به یک برنامه روی EC2 می‌رسد. سپس جهت مخالف را امتحان می‌کنید، از EC2 به نشانی‌ای که به کارخواه اختصاص یافته، و اتصال معلق می‌ماند یا رد می‌شود. این عدم تقارن به‌ندرت به‌خاطر قاعده گمشده در گروه امنیتی است. روی نقطه پایانی Client VPN که به زیرشبکه‌های VPC متصل است، AWS منابع IPv4 کارخواه را به رابط شبکه نقطه پایانی ترجمه می‌کند، بنابراین هیچ نشانی ورودی در VPC که نماینده لپ‌تاپ شما باشد وجود ندارد.
با آنچه ضبط بسته‌ها نشان می‌دهد شروع کنید
هنگام اتصال کارخواه، روی میزبان EC2 ضبط بسته بگیرید و نشانی مبدأیی را که برنامه واقعاً می‌بیند بخوانید. اگر رابط نقطه پایانی در سمت VPC باشد و نه نشانی‌ای از استخر کارخواه، ترجمه پیش از تغییر حتی یک قاعده تأیید شده است.
استخر کارخواه یک بازه تخصیص است، نه زیرشبکه‌ای با مسیر بازگشت. همین تمایز جایی است که بیشتر این بررسی‌ها به بیراهه می‌روند.
ترجمه‌ای که عدم تقارن را توضیح می‌دهد
سه جریان با هم اشتباه گرفته می‌شوند و تنها یکی از آن‌ها همانی است که مردم آزمایش می‌کنند.
| Flow | Started by | What the VPC sees | Outcome |
|---|---|---|---|
| Client to EC2 service | The client | A translated source at the endpoint interface | Works, with a stateful reply |
| EC2 host to client pool address | The EC2 host | A destination with no route and no translation state | No usable path |
| Client to client | A client, when the feature is configured | Traffic mediated by the endpoint | Works only with that feature and its authorisation |
توصیف اجزای Client VPN صریحاً می‌گوید منابع IPv4 کارخواه به رابط نقطه پایانی ترجمه می‌شوند، و همین کافی است تا ببینیم چرا ردیف میانی چیزی برای تطبیق ندارد.
اتصال تازه به مسیر، گام تجزیه نشانی و تصمیم مجوز نیاز دارد. وضعیت ترجمه از نشست شخص دیگری هیچ‌یک از این سه را فراهم نمی‌کند.
چرا پاسخ یک اتصال تازه نیست
پاسخ TCP با یک ورودی موجود تطبیق داده می‌شود، به همین دلیل مسیر بازگشت بدون هیچ قاعده ورودی کار می‌کند. SYN تازه از میزبان EC2 ورودی‌ای برای تطبیق ندارد، پس به یک تلاش خروجی معمولی به مقصدی تبدیل می‌شود که VPC نمی‌داند چگونه به آن برسد.
به همین دلیل هم توصیف این وضعیت به‌عنوان ترافیکی که فقط یک‌طرفه می‌رود گمراه‌کننده است. ترافیک بازگشت در این نشست‌ها پیوسته جریان دارد. بخش بدون مسیر، آغازگری است.
چه چیز هنوز نشستی را که باید کار کند خراب می‌کند
گروه‌های امنیتی، فهرست‌های کنترل دسترسی شبکه و دیوار آتش خود لپ‌تاپ همه برای اتصالاتی که باید موفق شوند اهمیت دارند. ping ناموفق کمترین اطلاعات را می‌دهد، چون سیاست ICMP غالباً از سیاست TCP که برایتان مهم است جداست.
این قواعد را بر اساس مبدأ ترجمه‌شده بنویسید، نه نشانی کارخواه. قواعدی که به نشانی‌ای گره خورده‌اند که هرگز روی شبکه دیده نمی‌شود، شایع‌ترین خرابی خودساخته در این طراحی هستند.
وقتی VPC واقعاً باید گفت‌وگو را آغاز کند
اگر خدمتی باید به یک ایستگاه کاری اطلاع بدهد، جهت را برعکس کنید و بگذارید کارخواه کانال خروجی پایدار نگه دارد که خدمت روی آن پاسخ می‌دهد. اگر کل یک شبکه دوردست باید از VPC در دسترس باشد، معماری‌ای انتخاب کنید که پیشوندها و سیاست دسترسی خود را منتشر می‌کند به‌جای آنکه فرض کنید Client VPN از قبل این کار را می‌کند. دسترسی کارخواه به کارخواه سومین مورد، باریک‌تر، با اشیای مسیر و مجوز خودش است. هیچ‌یک از این‌ها فقط یک کادر تیک روی نقطه پایانی موجود نیست.
دامنه توضیح IPv4 را هم صادقانه نگه دارید. مستندات کنونی AWS، IPv6 را که این ترجمه در آن اعمال نمی‌شود جدا می‌کند، و همچنین مدل‌های اتصال دیگری را که مسیریابی متفاوتی دارند.
در سه گام برچسب‌خورده آزمایش کنید: کارخواه یک نشست مجاز باز می‌کند، خدمت VPC به آن نشست پاسخ می‌دهد، و میزبانی در VPC نشست تازه‌ای به سمت کارخواه باز می‌کند. موفقیت دو مورد نخست در حالی که سوم شکست می‌خورد، شکل مورد انتظار این طراحی است، نه نقصی که با قواعد دیوار آتش دنبال شود.