چرا وارد کردن مجدد گواهی Client VPN به نقطه پایانی جدید نیاز دارد

اتصال Client VPN قطع می‌شود، گواهی موجود در ACM جایگزین می‌شود و هیچ چیز تغییر نمی‌کند. شیء گواهی هرگز همان چیزی نبود که نقطه پایانی از آن استفاده می‌کرد. نقطه پایانی در زمان ساخت، پیوندی با یک گواهی را ذخیره می‌کند، همراه با CA مشتری که در برابر آن اعتبارسنجی می‌کند، نوع احراز هویت، زیرشبکه‌ها و قواعد مجوز، و هیچ‌یک از این پیوندها فراخوان تغییر ندارد که گواهی جایگزین را بپذیرد. جایگزین کردن بایت‌های پشت یک ARN تغییری در گواهی است، نه در نقطه پایانی‌ای که آن را ثبت کرده بود.

نقطه پایانی مراجع را ذخیره می‌کند، نه گواهی‌ها را

ارزش دارد سازوکار را دقیق بیان کنیم، چون کل خرابی را توضیح می‌دهد. create-client-vpn-endpoint یک ARN گواهی سرور و یک ARN زنجیره گواهی ریشه مشتری می‌گیرد، و نقطه پایانی حاصل آن مراجع را همراه با گزینه‌های احراز هویت به‌عنوان ویژگی‌های ثابت نگه می‌دارد. سطح API هیچ عملیاتی ارائه نمی‌دهد که گواهی سرور را روی نقطه پایانی موجود عوض کند.

می‌توانید پیوند را بدون حدس زدن تأیید کنید. aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 ARN گواهی، ARN زنجیره ریشه مشتری، نوع احراز هویت، CIDR مشتری و زیرشبکه‌های مرتبط را چاپ می‌کند، که همان مجموعه کامل ویژگی‌هایی است که باید بازتولید می‌کردید. آن را پیش و پس از وارد کردن مجدد اجرا کنید و خروجی تکان نمی‌خورد. این همان شواهدی است که نشان می‌دهد وارد کردن مجدد هرگز قرار نبود کمک کند.

چرا وارد کردن مجدد نمی‌تواند به نقطه پایانی برسد

وارد کردن مجدد، بدنه گواهی جدیدی زیر یک ARN موجود می‌نویسد. این وقتی گواهی نزدیک انقضاست عملیاتی مشروع است، و ACM آن را می‌پذیرد تا زمانی که کلید خصوصی مطابقت داشته باشد و زنجیره معتبر باشد. کاری که نمی‌کند این است که اعتبارسنجی زمان ساخت نقطه پایانی را دوباره اجرا کند، پس پیوند و مواد پشت آن همان‌گونه می‌مانند که هنگام ساخت نقطه پایانی بودند.

به همین دلیل هم نشانه شبیه خرابی شبکه به نظر می‌رسد. دست‌دهی TLS شکست می‌خورد یا پیش از آنکه مجوز هرگز ارزیابی شود بازنشانی می‌شود، پس گروه‌های امنیتی، مسیرها و قواعد مجوز همه بی‌گناه به نظر می‌رسند، و همین‌طور هم هستند.

زنجیره بخشی از گواهی مشتری است

نیمه دوم خرابی در گواهی مشتری است، و رد کردن آن آسان‌تر است. گواهی مشتری باید همراه با زنجیره‌ای که آن را صادر کرده وارد شود، هرچند فرم ورود آن فیلد را اختیاری نشان می‌دهد. بدون زنجیره، نقطه پایانی نمی‌تواند مسیری از گواهی مشتری تا CA ریشه مشتری که با آن پیکربندی شده بود بسازد، و اتصال با بازنشانی نرمی پایان می‌یابد که شبیه دیوار آتشی است که بسته‌ها را می‌اندازد. openssl verify -CAfile root-ca.pem client.crt به آن پرسش به‌صورت محلی در یک ثانیه پاسخ می‌دهد، و باید اولین فرمانی باشد که اجرا می‌کنید.

وارد کردن مجدد همراه با زنجیره برای آن نیمه اصلاح واقعی است، و با این حال به‌تنهایی کافی نیست. وقتی شیء ACM تغییر کرد، نقطه پایانی‌ای که پیوند قدیمی را نگه می‌دارد چیز اشتباهی برای ادامه آزمایش است. هر دو گام به یک تعمیر تعلق دارند، به همین دلیل اصلاح دوجزئی تناقض نیست.

بازسازی نقطه پایانی یک مهاجرت است

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

ترتیبی که این را ایمن نگه می‌دارد کوتاه است: نقطه پایانی جدید را با همان CIDR، زیرشبکه‌ها و قواعد مجوز بسازید، با aws ec2 export-client-vpn-client-configuration پروفایل تازه‌ای صادر کنید، و با یک کاربر تأیید کنید. تنها پس از آن نقطه پایانی قدیمی پایین می‌آید.

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

تشخیص را مرتب کنید

پیش از تغییر هر پیکربندی، سه خرابی را جدا کنید. مشتری نمی‌تواند TLS را کامل کند، مشتری TLS را کامل می‌کند و مجاز نیست، یا مشتری متصل می‌شود و به مقصدی نمی‌رسد. پیوند گواهی به اولی تعلق دارد، قاعده مجوزی که نشانی مشتری را پوشش نمی‌دهد به دومی، و مسیر یا گروه امنیتی به سومی، جایی که بازسازی نقطه پایانی تقریباً همیشه گام اشتباه است.

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

چهار چیز را زیر کنترل نسخه نگه دارید تا بازسازی بعدی یک diff باشد نه بداهه‌سازی: پارامترهای نقطه پایانی، ARNهای گواهی و زنجیره، قواعد مجوز و CIDR مشتری. مستندات احراز هویت Client VPN فهرست می‌کند که کدام گواهی چه نقشی دارد، و ارزش دارد پیش از آنکه اصلاً فرض کنید گواهی مشکل است آن را بررسی کنید. اگر وارد کردن مجدد چیزی را تغییر نمی‌دهد و نقطه پایانی همچنان بازنشانی می‌شود، پیوند مشکوک است و پاسخ نقطه پایانی جدیدی است که از پارامترهای ثبت‌شده ساخته می‌شود. اگر نقطه پایانی واقعاً شیء جدید را بردارد، پیوند از قبل درست بوده و خرابی در زنجیره مشتری یا لایه مجوز است.