AWS Client VPN یا Site-to-Site: بررسی کنید چه کسی اتصال را باز می‌کند
Client VPN دستگاه یا کاربر را احراز هویت می‌کند؛ Site-to-Site یک دروازه را به AWS وصل می‌کند. چهار بررسی تعیین می‌کند لپ‌تاپ یا شعبه شما واقعاً به کدام نیاز دارد.
چهار بررسی این را تعیین می‌کند و هیچ‌یک از آن‌ها نام پروتکل نیست. چه کسی اتصال را باز می‌کند، AWS چه چیزی را احراز هویت می‌کند، اتصال چگونه به شبکه شما متصل می‌شود، و چه مسیریابی و سیاستی همراه آن می‌آید. به این‌ها به ترتیب پاسخ دهید و انتخاب محصول معمولاً خودش انجام می‌شود؛ اگر بعد از خرید یک طراحی پاسخ دهید، از تونلی دفاع می‌کنید که نیمه اشتباه مسئله را حل می‌کند. هیچ‌یک از این چهار از شما نمی‌خواهد رمزنگاری انتخاب کنید، و به همین دلیل طراحی‌ای که با پروتکل شروع می‌شود معمولاً نشانه آن است که الزامات هرگز نوشته نشده‌اند.
هر بررسی را روی نقطه پایانی، کارخواه و خانواده نشانی واقعی که قصد استفاده از آن را دارید اجرا کنید، نه روی دسته‌بندی. محصولات VPN مدیریت‌شده با بلوک‌های سازنده OpenVPN و IPsec که شبیه آن‌ها هستند تفاوت دارند.
نخست، چه کسی اتصال را باز می‌کند
اگر چیزی که به دسترسی نیاز دارد یک لپ‌تاپ، یک تلفن یا ایستگاه کاری یک مدیر باشد، اتصال از یک دستگاه راه‌دور آغاز می‌شود و طراحی، دسترسی کارخواه راه‌دور است. اگر چیزی که به دسترسی نیاز دارد شعبه‌ای پر از ماشین‌ها پشت یک مسیریاب باشد، اتصال از همان مسیریاب آغاز می‌شود و طراحی، دروازه‌به‌دروازه است. این همان بررسی است که بیشتر موارد را تعیین می‌کند، و همان چیزی است که مردم وقتی ارائه یک فروشنده گفتگو را از پیش حول رمزنگاری‌ها چارچوب‌بندی کرده نادیده می‌گیرند.
اگر نمی‌توانید مؤلفه‌ای را که آغاز می‌کند نام ببرید، همین‌جا بایستید. طراحی‌ای که می‌کوشد هر دو حالت را با یک تونل پوشش دهد معمولاً به نشست کارخواهی می‌رسد که خود را دروازه جا می‌زند.
دوم، AWS چه چیزی را احراز هویت می‌کند
با Client VPN، AWS هویت کارخواه یا کاربر پیکربندی‌شده را احراز می‌کند: گواهی‌ها، یک دایرکتوری یا هویت فدرال، بسته به تنظیمات. با Site-to-Site VPN، AWS هویت همتای دروازه را احراز می‌کند. این تفاوت ظاهری نیست. یک مدل با افزودن کاربران و لغو اعتبارنامه‌هایشان مقیاس می‌گیرد؛ مدل دیگر با اعتماد به هر چیزی که پشت یک دروازه واحد قرار دارد مقیاس می‌گیرد.
احراز هویت دروازه، هر کارمند یا برنامه‌ای را که پشت آن است احراز نمی‌کند، پس هویت برنامه‌ها و دسترسی در سطح منبع را حتی وقتی خود تونل قابل اعتماد است حفظ کنید. شعبه‌ای که مسیریابش هویت همتای معتبر دارد نباید به‌طور خودکار طوری خوانده شود که گویی هر میز در آن ساختمان مجاز است.
سوم، اتصال چگونه متصل می‌شود
Client VPN از طریق انجمن‌های زیرشبکه VPC یا اتصال مستقیم پشتیبانی‌شده به Transit Gateway متصل می‌شود. Site-to-Site VPN به یک هدف AWS VPN متصل می‌شود، معمولاً یک دروازه خصوصی مجازی یا یک Transit Gateway. راهنمای معماری Client VPN گزینه Transit Gateway را مستند می‌کند، و وجود آن نشست لپ‌تاپ را به دروازه شعبه تبدیل نمی‌کند و احراز هویت و مجوز کارخواهی را که در بالا توصیف شد حذف نمی‌کند.
اتصالی را که حساب و منطقه شما واقعاً پشتیبانی می‌کند پیش از طراحی مسیرها حول آن بررسی کنید، سپس بررسی کنید که آن اتصال از آنِ چه کسی است. گزینه‌ای که در مستندات وجود دارد اما روی شبکه‌ای قرار دارد که نمی‌توانید پیکربندی کنید، گزینه نیست.
چهارم، چه مسیریابی و سیاستی همراه آن می‌آید
Client VPN مدیریت اتصال کارخواه و قواعد مجوز برای شبکه‌های مقصدی که اجازه می‌دهید را می‌آورد. کاربر متصل هنوز به مسیر مورد نظر تا نقطه پایانی، قاعده مجوزی که آن را اجازه می‌دهد، و هر دسترسی که خود منبع می‌طلبد نیاز دارد. Site-to-Site VPN بین شبکه‌هایی که با دروازه مشتری نمایندگی می‌شوند مسیریابی می‌کند و بسته به طراحی از مسیرهای ایستا پشتیبانی‌شده یا BGP استفاده می‌کند، بنابراین ماشین‌های منفرد پشت مسیریاب شعبه هرکدام به ورود کارخواه نیاز ندارند.
در هیچ جهت رفتار پشتیبانی‌نشده را از دسته‌بندی استنتاج نکنید. VPNهای دسترسی راه‌دور به‌طور کلی ناتوان از حمل ترافیک بازگشتی یا پشتیبانی از آرایش‌های دروازه نیستند، و IPsec به‌طور خودکار توسط NAT مسدود نمی‌شود — AWS عبور از NAT و الزامات دروازه مشتری را مستند می‌کند، و محدودیت واقعی پیکربندی دروازه پشتیبانی‌شده است. پیش از آنکه اتصال‌های آغازشده به سمت کارخواه‌ها را الزامی کنید یا یک LAN را پشت یک نشست هدایت کنید، محدودیت‌های نقطه پایانی خود را بررسی کنید. همین احتیاط برای خانواده‌های نشانی هم صادق است: نقطه پایانی‌ای که روی IPv4 کار می‌کند به معنای مسیر IPv6 نیست، پس خانواده‌ای را که کارخواه یا دروازه شما واقعاً مذاکره خواهد کرد تأیید کنید.
Site-to-Site VPN به شما دو تونل در هر اتصال می‌دهد و آن افزونگی یک وظیفه طراحی است نه ویژگی‌ای که بتوان فرض کرد. عملیات دروازه مشتری، جابه‌جایی مسیر در خطا و پوشش آزمون همه باید برنامه‌ریزی شوند؛ مقایسه یک نشست لپ‌تاپ با یک سرور VPN انتزاعی چیزی را درباره هیچ‌یک اثبات نمی‌کند.
جایی که دو طراحی به هم می‌رسند
این سرویس‌ها انحصاری نیستند و شکل تولیدی رایج از هر دو استفاده می‌کند: کارمندان روی Client VPN، شبکه‌های شعبه روی Site-to-Site، با مسیرهای صریح و سیاست دسترسی بین مقصدهایی که باید با هم صحبت کنند. جدول خلاصه چهار بررسی است، نه جانشین اجرای آن‌ها.
| Question | AWS Client VPN | AWS Site-to-Site VPN |
|---|---|---|
| Who establishes it? | A client on a remote device | A customer gateway device or appliance |
| What is authenticated? | The client or user identity | The gateway peer identity |
| How does it attach? | VPC subnet association or Transit Gateway | Virtual private gateway or Transit Gateway |
| What carries the path? | An OpenVPN-based client tunnel | IPsec tunnels to AWS endpoints |
چیزی که هیچ‌یک از دو محصول جایگزینش نمی‌شود: TLS به برنامه‌ای که الزام رمزنگاری‌اش فراتر از نقطه پایانی VPN می‌رود. اگر دامنه انطباق شما در برنامه تمام می‌شود، تونل حمل‌ونقل است و گواهی همچنان کنترل است.
چهار پاسخ را پیش از بازبینی طراحی بنویسید، هر یک در یک خط. وقتی دو تا از آن‌ها ناسازگار باشند — مثلاً طراحی کارخواهی با احراز هویت کاربر و الزام مسیریابی به اندازه شعبه — همان ناسازگاری یافته است، و دیدنش اکنون ارزان‌تر از دیدنش هنگام مهاجرت است.