CIDR الخاص بعميل AWS Client VPN لا يمكن أن يتقاطع مع نطاق VPC

توزّع نقطة نهاية 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، وهو أسرع من التفكير في أقنعة الشبكة عند نهاية نافذة تغيير.

للمُحلِّل دور عنوان خاص به

يجيب مُحلِّل VPC على العنوان الأساسي لنطاق VPC زائد اثنين، وهو ليس بالضرورة داخل الشبكة الفرعية التي ربطتها. افتراض أن المُحلِّل يجب أن يعيش داخل تجمّع العملاء، أو بناء شبكة فرعية حول ذلك العنوان، يضيف كائنات دون أن يغيّر شيئاً. المهم أن تحمل نقطة النهاية إعداد DNS يستطيع العميل تطبيقه وأن يكون المُحلِّل قابلاً للوصول من النفق.

سجّل المُحلِّل وتجمّع العملاء والشبكة الفرعية المرتبطة كثلاثة بنود منفصلة في خطة العناوين. تفشل هذه مستقلة، وكون أحدها صحيحاً لا يقول شيئاً عن الاثنين الآخرين.

أربعة حقول تلتزم بها عند الإنشاء

CIDR الخاص بالعميل IPv4 ثابت عند الإنشاء. تغيير خادم DNS، أو إضافة ارتباط، أو تبديل مجموعة الأمان، أو تعديل قواعد التخويل، أو تغيير مسارات النفق المنقسم، كلها تعديلات عادية، ولا شيء منها يعيد تسمية التجمّع. هذا التفاوت هو سبب استحقاق الأمر للمراجعة: الإعدادات الرخيصة هي التي سترغب في تغييرها لاحقاً، والمكلفة هي التي تلتزم بها أولاً. اقرأ وصف نقطة النهاية قبل أن تخطط لنافذة تغيير.

افحص نقطة النهاية المنشورة قبل أن تفترض إعادة بناء. يعيد aws ec2 describe-client-vpn-endpoints التجمّع وDNS وعلم النفق المنقسم والارتباطات في استجابة واحدة، وهو عادةً كافٍ لاستبعاد إعادة البناء.

استبدل نقطة النهاية بدل ترقيعها

نقطة النهاية الجديدة نقطة نهاية جديدة، لا ترحيل. الجلسات القائمة لا تنتقل إليها، وملفات تعريف العملاء تشير إلى اسم مختلف، وكل إعداد اعتبرته مسلّماً به يجب إعادة إنشائه: شهادة الخادم، والمصادقة، والارتباطات، والمسارات، ومجموعات التخويل، والتسجيل. تحقّق بعميل واحد مقابل خدمة خاصة مطلوبة ومقابل وجهة يجب رفضها، ثم وسّع الوصول. أي شيء تتخطّاه يصبح تذكرة دعم لاحقاً.

أبقِ نقطة النهاية القديمة عاملة حتى ينجح ذلك التحقق، واحتفظ بمسار إداري لا يعتمد على الجديدة.

حدّ واحد يستحق الذكر: هذا يغطي تجمّع عملاء IPv4. إعدادات حركة dual-stack وIPv6 على Client VPN تتبع نموذج عنونة خاصاً بها، فلا تنسخ هذه القائمة دون قراءة الوثائق الخاصة بذلك الوضع.