الوصول إلى Customer Edge

تعمل أربعة مسارات، ويُحدَّد المسار المنطبق بحالة العقدة، وبالمكان الذي تتصل منه، وبما تحتاج إلى الوصول إليه — وليس بالتفضيل الشخصي.

المسار	يتطلب أن تكون العقدة `ONLINE`	يتطلب إمكانية الوصول عبر الشبكة	القيود	ما يغطيه
واجهة API للتصحيح	نعم	نعم	نحو 25–30 دقيقة من التهيئة الأولية على موقع جديد	34 أمرًا
وحدة تحكم الموقع	لا	عبر Azure Bastion، دون الحاجة إلى مضيف وسيط	يجب أن يكون Bastion من فئة Standard SKU مع دعم الأنفاق، وهو غير منشور افتراضيًا	واجهة استكشاف أخطاء العقدة الخاصة بـ F5
SSH	لا	من داخل شبكة VNet، وإلى العنوان الداخلي فقط	يجب أن يكون المفتاح موجودًا من أول تشغيل	واجهة Site CLI الكاملة على الجهاز
وحدة التحكم التسلسلية	لا	لا	جلسة واحدة لكل جهاز افتراضي؛ حد لصق يبلغ 2,048 حرفًا	واجهة Site CLI الكاملة على الجهاز

وحدة التحكم التسلسلية هي الملاذ الأخير، والمسار الوحيد الذي يظل صالحًا مع عقدة لا تمتلك أي مسار شبكي عامل.

عادةً ما تكون وحدة تحكم الموقع هي أول ما تجربه. فهي أقل ما تطلبه منك — لا مفتاح SSH يجب توزيعه، ولا مضيف وسيط، ولا عنوان IP عام على العقدة، ولا استبدال للجهاز الافتراضي — لأن الوصول يصبح قرارًا يتعلق بـ Azure RBAC بدلًا من مشكلة توزيع بيانات اعتماد. وهي تمنحك واجهة استكشاف الأخطاء الخاصة بـ F5 بدلًا من سطح الأوامر، لذا تجاوزها عندما تحتاج إلى تنفيذ أوامر محددة أو كتابة أي نصوص برمجية. شرطها المسبق الوحيد هو Azure Bastion، الذي يجعله هذا النشر اختياريًا (enable_bastion، القيمة الافتراضية false) لأن مضيف Standard-SKU يُحاسب عليه سواء فتح أحدهم نفقًا أم لا.

SSH هو ما تلجأ إليه عندما لا تكون واجهة API للتصحيح كافية، لأن الجهاز يقدّم عددًا من الأوامر أكبر بكثير من الـ 34 التي تعرضها تلك الواجهة. وله تكلفتان. يُكتب المفتاح بواسطة cloud-init ولذلك يجب أن يكون موجودًا عند أول تشغيل، ما يعني أن تمكينه على العقد العاملة يستبدل كل جهاز افتراضي من أجهزة CE — أي إعادة بناء للأسطول بدلًا من تغيير في الإعدادات. كما أن sshd يستجيب على العنوان الداخلي للعقدة فقط، لذا يحتاج إلى مضيف داخل شبكة VNet؛ وفحص العنوان الذي تعرف العقدة به سيُبلّغ دائمًا بأنه مغلق.

لماذا هذا الانقسام ليس مسألة تفضيل

تُقدَّم واجهة API للتصحيح من مستوى التحكم في F5 Distributed Cloud، الذي يُرحّل الطلبات إلى العقدة عبر النفق الذي يُنشئه vpm أثناء التسجيل. عدم التسجيل يعني عدم وجود نفق، ما يعني أن الواجهة لا تملك شيئًا لترحيل الطلبات إليه.

وهي تفشل بطريقة غير مفيدة بدلًا من طريقة واضحة، لذا فإن العقدة التي لم تعمل مطلقًا تبدو كأنها مشكلة في الواجهة.

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

بيانات الاعتماد

يستخدم كل مسار بيانات اعتماد مختلفة، ولا ينتمي أي منها إلى سطر الأوامر.

واجهة API للتصحيح — رمز API لـ F5 Distributed Cloud، بصيغة XCSH_API_TOKEN، مع عنوان URL للمستأجر بصيغة XCSH_API_URL. يحتوي ملف سياق xcsh الموجود في ~/.config/xcsh/contexts/<tenant>.json على كليهما، وهو ما يقرأه scripts/capture-sitecli.sh عندما لا توفّرهما البيئة. مستأجر هذا النشر هو f5-sales-demo؛ والرمز المُصدَر لمستأجر آخر يُعيد 401 مجردًا يُقرأ كأنه بيانات اعتماد منتهية الصلاحية.
وحدة تحكم الموقع — بيانات اعتماد اثنتان، في طبقتين مختلفتين. تسجيل دخولك التفاعلي إلى Azure يفتح نفق Bastion، وحساب admin الخاص بالجهاز يسجّل الدخول إلى وحدة التحكم الموجودة خلفه عبر HTTP Basic. وتنص Microsoft على أن جانب Azure يحتاج إلى صلاحية Reader على الجهاز الافتراضي وبطاقة الشبكة الخاصة به ومضيف Bastion؛ وهذا الشرط غير متحقَّق منه هنا، لأن كل الاختبارات نُفِّذت بصفة مالك الاشتراك.
SSH — النصف الخاص من زوج المفاتيح الذي كتب النشر نصفه العام في /var/home/admin/.ssh/authorized_keys عند أول تشغيل، إضافة إلى مضيف داخل شبكة VNet للوصول من خلاله إلى العنوان الداخلي. اتصل بصفة admin، وليس azureuser.
وحدة التحكم التسلسلية — تسجيل دخولك التفاعلي إلى Azure. لا يوجد service principal لهذا الغرض: فمستأجر Entra المؤسسي لدى F5 لا يسمح بتوفير واحد، وهو أيضًا السبب في عدم تنفيذ أي جزء من هذا في CI.