कस्टमर एज तक पहुँच

चार मार्ग काम करते हैं, और कौन सा लागू होता है यह नोड की स्थिति, आप कहाँ से कनेक्ट कर रहे हैं, और आपको क्या पहुँचना है — इससे तय होता है, वरीयता से नहीं।

मार्ग	नोड `ONLINE` आवश्यक	नेटवर्क पहुँच आवश्यक	सीमाएँ	कवर करता है
Debug API	हाँ	हाँ	नई साइट पर लगभग 25–30 मिनट का वार्म-अप	34 कमांड
Site Console	नहीं	Azure Bastion के ज़रिए, कोई जंप होस्ट आवश्यक नहीं	Bastion को टनलिंग के साथ Standard SKU होना चाहिए, और यह डिफ़ॉल्ट रूप से तैनात नहीं होता	F5 का नोड ट्रबलशूटिंग UI
SSH	नहीं	VNet के भीतर से, केवल आंतरिक पते पर	कुंजी पहले बूट से मौजूद होनी चाहिए	पूरा ऑन-बॉक्स Site CLI
सीरियल कंसोल	नहीं	नहीं	प्रति VM एक सत्र; 2,048-अक्षर पेस्ट सीमा	पूरा ऑन-बॉक्स Site CLI

सीरियल कंसोल अंतिम उपाय है, और एकमात्र ऐसा मार्ग है जो बिना किसी कार्यशील नेटवर्क पथ वाले नोड पर भी टिका रहता है।

Site Console आमतौर पर सबसे पहले आज़माने वाला विकल्प है। यह आपसे सबसे कम मांगता है — कोई SSH कुंजी वितरित नहीं करनी, कोई जंप होस्ट नहीं, नोड पर कोई सार्वजनिक IP नहीं, और कोई VM प्रतिस्थापन नहीं — क्योंकि पहुँच एक क्रेडेंशियल-वितरण समस्या के बजाय Azure RBAC निर्णय बन जाती है। यह आपको कमांड सतह के बजाय F5 का स्वयं का ट्रबलशूटिंग UI देता है, इसलिए जब आपको विशिष्ट कमांड चलाने हों या कुछ स्क्रिप्ट करना हो तो इससे आगे जाएँ। इसकी एक ही पूर्वापेक्षा Azure Bastion है, जिसे यह तैनाती ऑप्ट-इन बनाती है (enable_bastion, डिफ़ॉल्ट false) क्योंकि एक Standard-SKU होस्ट का बिल तब भी बनता है जब कोई टनल न खोले।

SSH तब काम आता है जब debug API पर्याप्त न हो, क्योंकि उपकरण उन 34 कमांडों से काफ़ी अधिक कमांड प्रदान करता है जिन्हें वह API उजागर करता है। इसकी दो लागतें हैं। कुंजी cloud-init द्वारा लिखी जाती है और इसलिए पहले बूट पर मौजूद होनी चाहिए, जिसका अर्थ है कि चल रहे नोड्स पर इसे सक्षम करने से हर CE VM बदल जाता है — यह एक कॉन्फ़िगरेशन परिवर्तन के बजाय फ़्लीट पुनर्निर्माण है। और sshd केवल नोड के आंतरिक पते पर उत्तर देता है, इसलिए इसे VNet के भीतर एक होस्ट की आवश्यकता होती है; जिस पते से आप नोड को जानते हैं उसे प्रोब करने पर सदैव बंद ही रिपोर्ट होगा।

यह विभाजन वरीयता का विषय क्यों नहीं है

debug API को F5 Distributed Cloud कंट्रोल प्लेन द्वारा सर्व किया जाता है, जो पंजीकरण के दौरान vpm द्वारा स्थापित टनल के माध्यम से नोड तक रिले करता है। पंजीकरण नहीं होने का अर्थ है कोई टनल नहीं, जिसका अर्थ है कि API के पास रिले करने के लिए कुछ नहीं है।

यह स्पष्ट तरीके से न होकर एक अनुपयोगी तरीके से विफल होता है, इसलिए वह नोड जो कभी ऊपर ही नहीं आया, एक API समस्या जैसा दिखता है।

सीरियल कंसोल पूरी तरह दूसरी दिशा में जाता है — Azure प्लेटफ़ॉर्म के माध्यम से नोड के एमुलेटेड सीरियल पोर्ट तक। इसे इससे कोई मतलब नहीं कि नोड ने पंजीकरण किया है, उसकी नेटवर्क पहुँच है, या उसका डेटा प्लेन कार्यशील है। यही स्वतंत्रता पूरा उद्देश्य है, और यही कारण है कि CE VMs पर बूट डायग्नोस्टिक्स को सक्षम बनाए रखना आवश्यक है।

क्रेडेंशियल

प्रत्येक मार्ग भिन्न क्रेडेंशियल का उपयोग करता है, और उनमें से कोई भी कमांड लाइन पर नहीं होना चाहिए।

Debug API — एक F5 Distributed Cloud API टोकन, XCSH_API_TOKEN के रूप में, और टेनेंट URL XCSH_API_URL के रूप में। ~/.config/xcsh/contexts/<tenant>.json पर स्थित xcsh कॉन्टेक्स्ट फ़ाइल दोनों को रखती है, और जब परिवेश इन्हें प्रदान नहीं करता तो scripts/capture-sitecli.sh इसी को पढ़ता है। इस तैनाती का टेनेंट f5-sales-demo है; किसी अन्य टेनेंट के लिए बनाया गया टोकन एक सादा 401 लौटाता है जो एक समाप्त हो चुके क्रेडेंशियल जैसा प्रतीत होता है।
Site Console — दो क्रेडेंशियल, भिन्न स्तरों पर। आपका इंटरैक्टिव Azure लॉगिन Bastion टनल खोलता है, और उपकरण का स्वयं का admin खाता उसके पीछे HTTP Basic के माध्यम से कंसोल में साइन इन करता है। Microsoft के अनुसार Azure पक्ष को VM, उसके NIC और Bastion होस्ट पर Reader की आवश्यकता होती है; वह आवश्यकता यहाँ सत्यापित नहीं है, क्योंकि प्रत्येक परीक्षण सब्सक्रिप्शन ओनर के रूप में चलाया गया।
SSH — उस कीपेयर का निजी भाग जिसका सार्वजनिक भाग तैनाती ने पहले बूट पर /var/home/admin/.ssh/authorized_keys में लिखा था, साथ ही VNet के भीतर एक होस्ट जिसके माध्यम से आंतरिक पते तक पहुँचा जा सके। azureuser के रूप में नहीं, admin के रूप में कनेक्ट करें।
सीरियल कंसोल — आपका इंटरैक्टिव Azure लॉगिन। इसके लिए कोई सर्विस प्रिंसिपल नहीं है: F5 कॉर्पोरेट Entra टेनेंट किसी को प्रोविज़न करने की अनुमति नहीं देता, जो यह भी कारण है कि इसका कोई भाग CI में नहीं चलता।