AWS Client VPN: گواهی سرور در برابر نقش گواهی کلاینت
گواهی سرور نقطه پایانی، سرویس را اثبات می‌کند. احراز هویت دوطرفه هویت هر کلاینت و اعتماد به CA را بدون اشتراک کلید سرور اضافه می‌کند.
نقطه پایانی Client VPN همیشه به یک گواهی TLS سرور نیاز دارد. این همان هویتی است که نقطه پایانی مدیریت‌شده هنگام اتصال کلاینت ارائه می‌کند. این شیئی متفاوت از گواهی‌هایی است که کلاینت‌های منفرد در حالت احراز هویت دوطرفه ارائه می‌کنند. اشتباه گرفتن این دو، رایج‌ترین دلیل شکست یک پیکربندی ACM است که در بقیه موارد درست است، در همان اتصال نخست.
در ادامه، مسیری از کنسول به سمت بیرون و به همان ترتیبی که یک اتصال واقعاً طی می‌کند آمده است.
دو نقش، یک نقطه پایانی
نقطه پایانی هویت سرور و به‌صورت اختیاری ابزاری برای تأیید هویت کلاینت‌ها دارد. این دو جداگانه پیکربندی می‌شوند. یکی تعیین می‌کند آیا کلاینت می‌تواند به سرویس اعتماد کند؛ دیگری تعیین می‌کند آیا سرویس کلاینت را می‌پذیرد.
| Material | Purpose | Where it lives |
|---|---|---|
| Server certificate and private key | The managed endpoint proves its TLS identity | ACM, in the endpoint's Region |
| Client certificate and matching key | An individual client proves its identity | On the device |
| CA trust material | The verifier checks the issuer chain | Selected for the client role |
جدول را سه نیاز مستقل بخوانید، نه یک گواهی. گواهی سرور و کلید خصوصی آن نزد سرویس می‌مانند. گواهی کلاینت و کلید خصوصی متناظر روی دستگاه قرار دارند. مواد CA همان چیزی است که تأییدکننده برای بررسی زنجیره به کار می‌برد. فقط ردیف میانی است که هرگز به لپ‌تاپ تعلق دارد.
گواهی سرور ACM چه می‌کند
هنگام ساخت نقطه پایانی، گواهی سرور باید در ACM و در همان منطقه نقطه پایانی موجود باشد. کنسول یک ARN می‌خواهد و آن ARN باید همان‌جا قابل حل باشد. ACM می‌تواند گواهی‌ای را نگه دارد که با اعتبارسنجی دامنه تهیه کرده‌اید، یا گواهی‌ای که همراه کلید و زنجیره‌اش وارد کرده‌اید. هر دو در این نقش کار می‌کنند؛ تفاوتشان در تمدید و در این است که کلید خصوصی دست کیست.
مسیر تهیه را بر اساس اینکه چه کسی می‌تواند گواهی را تمدید کند انتخاب کنید، نه بر اساس مسیری که تصادفاً فایلی معتبر‌نما تولید کرد.
احراز هویت دوطرفه چه چیزی اضافه می‌کند
انتخاب احراز هویت کلاینت مبتنی بر گواهی، پرسش دومی اضافه می‌کند: کدام کلاینت‌ها اصلاً اجازه اتصال دارند. هر کلاینت گواهی خودش را ارائه می‌کند و مالکیت کلید خصوصی متناظر را اثبات می‌کند. همین هویت‌های جداگانه است که ابطال گزینشی را بعداً ممکن می‌کند. کپی کردن یک کلید کلاینت روی همه دستگاه‌ها بی‌صدا این ویژگی را دور می‌ریزد، حتی وقتی گواهی سرور بی‌عیب‌ونقص تهیه شده باشد.
روش احراز هویت نقطه پایانی یک انتخاب است، نه یک نیاز همگانی.
Active Directory و احراز هویت فدرال به همان پرسش با ابزارهای دیگر پاسخ می‌دهند. دستور گواهی دوطرفه به‌طور خودکار طرح ورود آن استقرارها نیست، و تأیید TLS سرور بدون توجه به شیوه پذیرش کاربر سر جایش می‌ماند.
چرا همان ARN مربوط به CA به معنای اشتراک کلید نیست
AWS مستند می‌کند که وقتی گواهی سرور و گواهی کلاینت را یک CA صادر کند، از ARN گواهی سرور می‌توان برای انتخاب گواهی کلاینت هم استفاده کرد. آن جمله درباره زنجیره‌ای است که نقطه پایانی هنگام تأیید به آن اعتماد می‌کند. این جمله به کلاینت‌ها نمی‌گوید از کلید خصوصی سرور استفاده کنند. لپ‌تاپ همچنان به گواهی کلاینت خودش و کلید متناظر خودش نیاز دارد.
وقتی CA کلاینت صادرکننده دیگری است، مسیر مستند این است که آن CA را به ACM وارد کنید و برای نقش کلاینت انتخابش کنید.
شکست را به یک مرحله بازگردانید
پیش از جایگزینی هر چیزی مشخص کنید کدام مرحله شکست می‌خورد. اگر کلاینت نقطه پایانی را رد می‌کند، ARN سرور یا زنجیره آن مشکوک است. اگر نقطه پایانی کلاینت را رد می‌کند، به گواهی کلاینت و صادرکننده آن و روش احراز هویت انتخاب‌شده نگاه کنید. اگر تونل بالا می‌آید و ترافیک هنوز شکست می‌خورد، از گواهی‌ها گذشته‌اید.
هر بار یک شیء را جایگزین کنید، چون عوض کردن هر دو سر هم‌زمان همان ابهامی را بازتولید می‌کند که با آن شروع کردید.
الگوریتم‌های کلید پشتیبانی‌شده و افزونه‌های لازم سرویس را برای نقش مشخص هم بررسی کنید. گواهی‌ای که یک وب‌سایت عمومی را راضی می‌کند، اثبات برآورده شدن همه نیازهای هویت Client VPN نیست.
بنویسید هر فیلد کدام ARN را نگه می‌دارد، کدام CA گواهی کلاینت را صادر کرده و نقطه پایانی واقعاً از کدام روش احراز هویت استفاده می‌کند. سه خط ثبت، تمدید بعدی را از یک تحقیق به یک کار تبدیل می‌کند.