نقطه پایانی AWS Client VPN آدرس‌های کلاینت را از استخری که خودتان انتخاب می‌کنید توزیع می‌کند و AWS پیش از ساخت نقطه پایانی آن استخر را با شبکه مقصد بررسی می‌کند. بررسی این نیست که آیا یک زیرشبکه آزاد به نظر می‌رسد. بررسی این است که آیا استخر با محدوده VPC هم‌پوشانی دارد، و پاسخ یکسان است چه یک نمونه EC2 امروز از آن آدرس‌ها استفاده کند چه نه. هم‌پوشانی پرسشی درباره محدوده‌ها است، نه درباره تخصیص‌ها.

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

هم‌پوشانی آزمون محدوده است، نه آزمون آدرس آزاد

از CIDR خود VPC شروع کنید، نه از زیرشبکه‌ای که قصد اتصال آن را دارید. استخری با 172.20.0.0/22 درون VPCی با 172.20.0.0/16 قرار می‌گیرد و رد می‌شود، حتی وقتی هیچ زیرشبکه‌ای آن را اشغال نکرده باشد، زیرا هم‌پوشانی ویژگی محدوده‌ها است نه تخصیص‌های کنونی. سپس مقصدهایی را که نقطه پایانی به آن‌ها مسیریابی می‌کند اضافه کنید: VPCهای همتا، یک گذرگاه ترانزیت و محدوده‌های محلی از طریق اتصال سایت‌به‌سایت. هر محدوده‌ای که کلاینت ممکن است به آن نیاز داشته باشد در فهرست جای دارد.

آن‌ها را از حساب جمع کنید نه از حافظه: aws ec2 describe-vpcs --query "Vpcs[].CidrBlock"، به‌همراه ورودی‌های جدول مسیریابی برای زیرشبکه‌ای که قصد اتصالش را دارید.

اندازه استخر پیش از ساخت تعیین می‌شود

AWS استخر کلاینت IPv4 را بین /22 و /12 در Client VPN می‌پذیرد. /24 بسیار کوچک است، /8 بیرون از محدوده مستند است، و هر دو خطا از اندازه‌گیری استخر مانند یک زیرشبکه بارکاری می‌آیند. آن را بر اساس کلاینت‌های هم‌زمان مورد انتظار به‌علاوه حاشیه اندازه بگیرید و سپس به پیشوند مجاز گرد کنید.

پیش از تایپ در کنسول، حساب را بررسی کنید، زیرا پیشوندی که اشتباه تایپ شود اندازه استخر را بدون هیچ هشداری تغییر می‌دهد:

python3 -c "import ipaddress; p=ipaddress.ip_network('172.16.0.0/22'); print(p.num_addresses, p.prefixlen, p.overlaps(ipaddress.ip_network('172.20.0.0/16')))"

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

resolver نقش آدرس خودش را دارد

resolver مربوط به VPC در آدرس پایه محدوده VPC به‌علاوه دو پاسخ می‌دهد، که لزوماً درون زیرشبکه‌ای که متصل کرده‌اید نیست. فرض اینکه resolver باید در استخر کلاینت زندگی کند، یا ساختن زیرشبکه‌ای پیرامون آن آدرس، اشیایی را اضافه می‌کند بدون آنکه چیزی را تغییر دهد. آنچه مهم است این است که نقطه پایانی تنظیم DNSای را حمل کند که کلاینت بتواند اعمال کند و resolver از تونل قابل دسترسی باشد.

resolver، استخر کلاینت و زیرشبکه متصل را به‌عنوان سه قلم جداگانه در طرح آدرس‌دهی ثبت کنید. آن‌ها مستقل شکست می‌خورند و درست بودن یکی چیزی درباره دو تای دیگر نمی‌گوید.

چهار فیلدی که هنگام ساخت به آن متعهد می‌شوید

CIDR IPv4 کلاینت هنگام ساخت ثابت است. تغییر سرور DNS، افزودن اتصال، تعویض گروه امنیتی، ویرایش قواعد مجازسازی یا تغییر مسیرهای split-tunnel همه ویرایش‌های معمولی هستند و هیچ‌کدام نام استخر را عوض نمی‌کند. همین عدم تقارن دلیل آن است که این کار شایسته بازبینی است: تنظیمات ارزان همان‌هایی هستند که بعداً می‌خواهید تغییر دهید و تنظیم گران همان است که نخست به آن متعهد می‌شوید. پیش از برنامه‌ریزی پنجره تغییر، توضیحات نقطه پایانی را بخوانید.

پیش از فرض بازسازی، نقطه پایانی مستقرشده را بررسی کنید. aws ec2 describe-client-vpn-endpoints استخر، DNS، نشانگر split-tunnel و اتصال‌ها را در یک پاسخ برمی‌گرداند که معمولاً برای رد کردن بازسازی کافی است.

نقطه پایانی را جایگزین کنید، نه وصله بزنید

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

نقطه پایانی قدیمی را تا گذر این اعتبارسنجی در حال اجرا نگه دارید و مسیر مدیریتی‌ای حفظ کنید که به نقطه پایانی جدید وابسته نباشد.

یک مرز که ارزش گفتن دارد: این مطلب استخر کلاینت IPv4 را پوشش می‌دهد. تنظیمات ترافیک dual-stack و IPv6 در Client VPN مدل آدرس‌دهی خودشان را دنبال می‌کنند، پس این فهرست را بدون خواندن مستندات آن حالت کپی نکنید.

مقالات مرتبط