चरण 1 — निर्माण

चरण 1 पूर्ण CSD इंफ्रास्ट्रक्चर को तैनात और सत्यापित करता है। सभी चरण क्रम में पूरे करें — प्रत्येक चरण आगे बढ़ने से पहले PASS होना चाहिए। इन कमांड को चलाने से पहले एनवायरनमेंट सेटअप और वेरिएबल रेज़ोल्यूशन पूरा करने के लिए इंडेक्स पर वापस जाएं।

चरण 0: नेमस्पेस जांचें और बनाएं (सशर्त)

जांचें कि क्या टेनेंट पर लक्ष्य नेमस्पेस पहले से मौजूद है। यदि यह मौजूद नहीं है, तो इसे बनाएं। परिणाम को NAMESPACE_CREATED शेल वेरिएबल में ट्रैक करें — चरण 4 के teardown में इसका उपयोग यह तय करने के लिए किया जाता है कि नेमस्पेस को हटाना है या नहीं।

NS_CHECK=$(curl -s -o /dev/null -w '%\{http_code\}' \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  "xF5XC_API_URLx/api/web/namespaces/xF5XC_NAMESPACEx")

NAMESPACE_CREATED="false"
if [ "$NS_CHECK" = "404" ]; then
  curl -s -X POST \
    -H "Authorization: APIToken xF5XC_API_TOKENx" \
    -H "Content-Type: application/json" \
    -d '{"metadata": {"name": "xF5XC_NAMESPACEx"}, "spec": {}}' \
    "xF5XC_API_URLx/api/web/namespaces" | jq .
  NAMESPACE_CREATED="true"
fi

टिप्पणी

spec फ़ील्ड आवश्यक है। F5 XC नेमस्पेस API को रिक्वेस्ट बॉडी में spec फ़ील्ड की आवश्यकता होती है, भले ही कोई कॉन्फ़िगरेशन की जरूरत न हो — एक खाली ऑब्जेक्ट {} पास करें। spec को छोड़ने पर error code 3 (“spec should not be empty in request”) आता है।

साक्ष्य

पुष्टि करें कि नेमस्पेस मौजूद है और रिकॉर्ड करें कि क्या यह बनाया गया था:

curl -s -o /dev/null -w '%\{http_code\}' \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  "xF5XC_API_URLx/api/web/namespaces/xF5XC_NAMESPACEx"
echo "NAMESPACE_CREATED=$NAMESPACE_CREATED"

फ़ील्ड	अपेक्षित	स्थिति
HTTP स्टेटस	200	यदि मिला तो PASS, 404 या अन्य हो तो FAIL
NAMESPACE_CREATED	true (बनाया गया) या false (पहले से मौजूद)	सूचनात्मक — चरण 4 teardown द्वारा उपयोग किया जाता है

चरण 1: हेल्थचेक बनाएं (वैकल्पिक)

एक HTTP हेल्थचेक बनाएं जिसका उपयोग ऑरिजिन पूल बैकएंड हेल्थ की निगरानी के लिए कर सकता है।

टिप्पणी

CSD के लिए हेल्थचेक वैकल्पिक हैं। क्लाइंट-साइड डिफेंस फीचर ऑरिजिन हेल्थ मॉनिटरिंग पर निर्भर नहीं करता। यदि आपके टेनेंट ने हेल्थचेक ऑब्जेक्ट सीमा समाप्त कर दी है (error code 8 — Error Handling देखें), तो इस चरण को छोड़ें और हेल्थचेक रेफरेंस के बिना ऑरिजिन पूल बनाएं। CSD सामान्य रूप से कार्य करेगा।

यदि आप हेल्थचेक बनाते हैं, तो इसे ऑरिजिन पूल से पहले बनाएं। ऑरिजिन पूल को एक मौजूदा हेल्थचेक का संदर्भ देना होगा — यदि ऑरिजिन पूल बनाते समय हेल्थचेक मौजूद नहीं है, तो रेफरेंस चुपचाप खाली रहेगा।

curl -s -X POST \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  -H "Content-Type: application/json" \
  -d '{
    "metadata": {
      "name": "xF5XC_HC_NAMEx",
      "namespace": "xF5XC_NAMESPACEx",
      "labels": {},
      "annotations": {},
      "disable": false
    },
    "spec": {
      "http_health_check": {
        "use_origin_server_name": {},
        "path": "/",
        "use_http2": false,
        "headers": {},
        "request_headers_to_remove": [],
        "expected_status_codes": ["200"]
      },
      "timeout": 3,
      "interval": 15,
      "jitter": 0,
      "unhealthy_threshold": 1,
      "healthy_threshold": 3,
      "jitter_percent": 30
    }
  }' \
  "xF5XC_API_URLx/api/config/namespaces/xF5XC_NAMESPACEx/healthchecks" \
  | jq .

200 रिस्पॉन्स के साथ बनाया गया ऑब्जेक्ट पुष्टि करता है कि हेल्थचेक बनाया गया था। यदि रिस्पॉन्स में "code": 8 के साथ "Object kind healthcheck has exhausted limits(150)" जैसा संदेश है, तो टेनेंट अपनी हेल्थचेक सीमा तक पहुंच गया है — चरण 2 पर जाएं और हेल्थचेक रेफरेंस हटा दें। CSD हेल्थ मॉनिटरिंग पर निर्भर नहीं करता।

साक्ष्य

पुष्टि करें कि हेल्थचेक मौजूद है:

curl -s \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  "xF5XC_API_URLx/api/config/namespaces/xF5XC_NAMESPACEx/healthchecks/xF5XC_HC_NAMEx" \
  | jq '{name: .metadata.name, namespace: .metadata.namespace, path: .spec.http_health_check.path, interval: .spec.interval}'

फ़ील्ड	अपेक्षित	स्थिति
HTTP स्टेटस	ऑब्जेक्ट के साथ 200	यदि मिला तो PASS, 404 हो तो FAIL
name	F5XC_HC_NAME से मेल खाता हो	PASS
path	/	PASS
चरण 1 छोड़ा गया (error code 8, सीमा समाप्त)	—	PASS (CSD के लिए हेल्थचेक वैकल्पिक है)

चरण 2: ऑरिजिन पूल बनाएं

अपने बैकएंड सर्वर की ओर इशारा करते हुए एक ऑरिजिन पूल बनाएं। यदि आपने चरण 1 में हेल्थचेक बनाया था, तो healthcheck रेफरेंस शामिल करें। यदि चरण 1 छोड़ा गया था, तो खाली array का उपयोग करें।

हेल्थचेक के साथ (चरण 1 सफल):

curl -s -X POST \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  -H "Content-Type: application/json" \
  -d '{
    "metadata": {
      "name": "xF5XC_ORIGIN_POOLx",
      "namespace": "xF5XC_NAMESPACEx",
      "labels": {},
      "annotations": {},
      "description": "Origin pool for CSD demo",
      "disable": false
    },
    "spec": {
      "origin_servers": [{
        "public_ip": { "ip": "xF5XC_ORIGIN_IPx" },
        "labels": {}
      }],
      "no_tls": {},
      "port": xF5XC_ORIGIN_PORTx,
      "same_as_endpoint_port": {},
      "healthcheck": [{
        "namespace": "xF5XC_NAMESPACEx",
        "name": "xF5XC_HC_NAMEx",
        "kind": "healthcheck"
      }],
      "loadbalancer_algorithm": "LB_OVERRIDE",
      "endpoint_selection": "LOCAL_PREFERRED"
    }
  }' \
  "xF5XC_API_URLx/api/config/namespaces/xF5XC_NAMESPACEx/origin_pools" \
  | jq .

हेल्थचेक के बिना (चरण 1 छोड़ा गया):

curl -s -X POST \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  -H "Content-Type: application/json" \
  -d '{
    "metadata": {
      "name": "xF5XC_ORIGIN_POOLx",
      "namespace": "xF5XC_NAMESPACEx",
      "labels": {},
      "annotations": {},
      "description": "Origin pool for CSD demo",
      "disable": false
    },
    "spec": {
      "origin_servers": [{
        "public_ip": { "ip": "xF5XC_ORIGIN_IPx" },
        "labels": {}
      }],
      "no_tls": {},
      "port": xF5XC_ORIGIN_PORTx,
      "same_as_endpoint_port": {},
      "healthcheck": [],
      "loadbalancer_algorithm": "LB_OVERRIDE",
      "endpoint_selection": "LOCAL_PREFERRED"
    }
  }' \
  "xF5XC_API_URLx/api/config/namespaces/xF5XC_NAMESPACEx/origin_pools" \
  | jq .

200 रिस्पॉन्स पुष्टि करता है कि ऑरिजिन पूल बनाया गया।

सावधानी

यदि रिस्पॉन्स में "code": 8 के साथ "Object kind endpoint has exhausted limits(500)" या "Object kind origin_pool has exhausted limits" जैसा संदेश है, तो टेनेंट ने अपनी कोटा सीमा पार कर ली है। हेल्थचेक के विपरीत, डेमो के लिए ऑरिजिन पूल आवश्यक हैं — एक के बिना डेमो आगे नहीं बढ़ सकता। क्षमता खाली करने के लिए अन्य नेमस्पेस से अप्रयुक्त ऑरिजिन पूल हटाएं (एक ऑरिजिन पूल को हटाने से इसके endpoint sub-objects भी मुक्त होते हैं), फिर पुनः प्रयास करें। यदि सीमा हल नहीं हो सकती, तो टेनेंट कोटा बढ़ाने के लिए अपने F5 Distributed Cloud (F5 XC) प्रशासक से संपर्क करें।

सत्यापित करें कि हेल्थचेक लिंक है

यदि आपने हेल्थचेक रेफरेंस शामिल किया था, तो पुष्टि करें कि यह सही तरीके से लिंक है:

curl -s \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  "xF5XC_API_URLx/api/config/namespaces/xF5XC_NAMESPACEx/origin_pools/xF5XC_ORIGIN_POOLx" \
  | jq '.spec.healthcheck'

एक populated array लिंक की पुष्टि करता है। यदि चरण 1 छोड़ा गया था तो खाली array [] अपेक्षित है, या इसका अर्थ है कि हेल्थचेक नहीं मिला यदि आप इसे लिंक करना चाहते थे।

साक्ष्य

पुष्टि करें कि ऑरिजिन पूल मौजूद है और सही कॉन्फ़िगरेशन है:

curl -s \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  "xF5XC_API_URLx/api/config/namespaces/xF5XC_NAMESPACEx/origin_pools/xF5XC_ORIGIN_POOLx" \
  | jq '{name: .metadata.name, origin_ip: .spec.origin_servers[0].public_ip.ip, port: .spec.port, healthcheck_count: (.spec.healthcheck | length)}'

फ़ील्ड	अपेक्षित	स्थिति
HTTP स्टेटस	200	यदि मिला तो PASS, 404 हो तो FAIL
name	F5XC_ORIGIN_POOL से मेल खाता हो	PASS
origin_ip	F5XC_ORIGIN_IP से मेल खाता हो	PASS
port	F5XC_ORIGIN_PORT से मेल खाता हो	PASS
healthcheck_count	1 (HC के साथ) या 0 (बिना)	PASS दोनों स्थिति में

चरण 3: CSD के साथ HTTP लोड बैलेंसर बनाएं

क्लाइंट-साइड डिफेंस सक्षम के साथ दो लोड बैलेंसर बनाएं — एक HTTP LB (प्राथमिक, पोर्ट 80) और एक HTTPS LB (द्वितीयक, पोर्ट 443 स्वचालित सर्टिफिकेट प्रबंधन के साथ)। HTTP LB सभी डेमो ट्रैफ़िक के लिए डिफ़ॉल्ट है। HTTPS LB एक अच्छा विकल्प है जो Let’s Encrypt सर्टिफिकेट प्रोविजनिंग पर निर्भर करता है, जो डेमो एनवायरनमेंट में दर सीमाओं तक पहुंच सकता है।

टिप्पणी

HTTP लोड बैलेंसर spec में 22+ oneOf choice group हैं। प्रत्येक group में ठीक एक choice सेट होना चाहिए, अन्यथा API 422 error देता है। नीचे दी गई कॉन्फ़िगरेशन CSD को छोड़कर सभी वैकल्पिक सुरक्षा सुविधाओं को अक्षम करती है — अपने एनवायरनमेंट के अनुसार संशोधित करें। दोनों LB एक ही ऑरिजिन पूल, CSD सेटिंग्स और डोमेन साझा करते हैं — केवल listener type अलग है।

संकेत

दोनों LB नाम F5XC_LB_NAME से प्राप्त होते हैं: HTTP LB ${F5XC_LB_NAME}-http है और HTTPS LB ${F5XC_LB_NAME}-https है। कोई अतिरिक्त एनवायरनमेंट वेरिएबल की आवश्यकता नहीं है।

HTTP लोड बैलेंसर (प्राथमिक)

यह डेमो के लिए प्राथमिक लोड बैलेंसर है। यह F5 XC managed DNS के साथ पोर्ट 80 पर http listener का उपयोग करता है। यह TLS सर्टिफिकेट प्रोविजनिंग पर निर्भर नहीं करता, इसलिए DNS resolve होने के तुरंत बाद तैयार हो जाता है।

curl -s -X POST \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  -H "Content-Type: application/json" \
  -d '{
    "metadata": {
      "name": "xF5XC_LB_NAMEx-http",
      "namespace": "xF5XC_NAMESPACEx",
      "labels": {},
      "annotations": {},
      "description": "HTTP LB with Client-Side Defense enabled (primary demo LB)",
      "disable": false
    },
    "spec": {
      "domains": ["xF5XC_DOMAINNAMEx"],
      "http": {
        "dns_volterra_managed": true,
        "port": 80
      },
      "advertise_on_public_default_vip": {},
      "default_route_pools": [{
        "pool": {
          "namespace": "xF5XC_NAMESPACEx",
          "name": "xF5XC_ORIGIN_POOLx",
          "kind": "origin_pool"
        },
        "weight": 1,
        "priority": 1
      }],
      "client_side_defense": {
        "policy": {
          "js_insert_all_pages": {}
        }
      },
      "disable_rate_limit": {},
      "no_service_policies": {},
      "round_robin": {},
      "disable_waf": {},
      "no_challenge": {},
      "disable_bot_defense": {},
      "disable_api_definition": {},
      "disable_api_discovery": {},
      "disable_ip_reputation": {},
      "disable_malicious_user_detection": {},
      "single_lb_app": {
        "disable_discovery": {},
        "disable_ddos_detection": {},
        "disable_malicious_user_detection": {}
      },
      "disable_trust_client_ip_headers": {},
      "user_id_client_ip": {},
      "disable_threat_mesh": {},
      "l7_ddos_action_default": {},
      "system_default_timeouts": {},
      "default_sensitive_data_policy": {},
      "disable_malware_protection": {},
      "disable_api_testing": {}
    }
  }' \
  "xF5XC_API_URLx/api/config/namespaces/xF5XC_NAMESPACEx/http_loadbalancers" \
  | jq .

200 रिस्पॉन्स पुष्टि करता है कि HTTP लोड बैलेंसर CSD सक्षम के साथ बनाया गया।

सावधानी

यदि रिस्पॉन्स में "code": 8 के साथ "Object kind http_loadbalancer has exhausted limits" जैसा संदेश है, तो टेनेंट ने अपनी लोड बैलेंसर कोटा सीमा पार कर ली है। डेमो के लिए लोड बैलेंसर आवश्यक हैं। क्षमता खाली करने के लिए अप्रयुक्त लोड बैलेंसर हटाएं, फिर पुनः प्रयास करें।

HTTPS लोड बैलेंसर (द्वितीयक)

यह द्वितीयक लोड बैलेंसर है। यह पोर्ट 443 पर स्वचालित Let’s Encrypt सर्टिफिकेट प्रोविजनिंग के साथ https_auto_cert का उपयोग करता है। इसे बनाने से पहले, जांचें कि क्या पिछले teardown से skeleton HTTPS LB मौजूद है — यदि है, तो मौजूदा Let’s Encrypt सर्टिफिकेट को संरक्षित करने और दर सीमाओं से बचने के लिए POST के बजाय PUT के माध्यम से इसे पुनर्स्थापित करें (प्रति सटीक identifier set प्रति 7 दिनों में 5 duplicate certificates)।

जांचें कि HTTPS LB पहले से मौजूद है या नहीं:

HTTPS_CHECK=$(curl -s -o /dev/null -w '%\{http_code\}' \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  "xF5XC_API_URLx/api/config/namespaces/xF5XC_NAMESPACEx/http_loadbalancers/xF5XC_LB_NAMEx-https")

यदि HTTPS_CHECK 200 है, तो एक skeleton HTTPS LB मौजूद है — Path A (PUT) का उपयोग करें। यदि 404 है, तो Path B (POST) का उपयोग करें।

Path A: PUT के माध्यम से Skeleton पुनर्स्थापित करें (HTTPS LB मौजूद है)

जब पिछले teardown से एक skeleton HTTPS LB मौजूद हो, तो PUT के माध्यम से पूर्ण कॉन्फ़िगरेशन पुनर्स्थापित करें। यह ऑरिजिन पूल को फिर से जोड़ता है और CSD को पुनः सक्षम करता है बिना नए Let’s Encrypt सर्टिफिकेट रिक्वेस्ट को ट्रिगर किए — मौजूदा सर्टिफिकेट वैध रहता है।

curl -s -X PUT \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  -H "Content-Type: application/json" \
  -d '{
    "metadata": {
      "name": "xF5XC_LB_NAMEx-https",
      "namespace": "xF5XC_NAMESPACEx",
      "labels": {},
      "annotations": {},
      "description": "HTTPS LB with Client-Side Defense enabled (secondary, cert-dependent)",
      "disable": false
    },
    "spec": {
      "domains": ["xF5XC_DOMAINNAMEx"],
      "https_auto_cert": {
        "http_redirect": false,
        "add_hsts": false,
        "port": 443,
        "default_header": {},
        "enable_path_normalize": {},
        "no_mtls": {},
        "default_loadbalancer": {}
      },
      "advertise_on_public_default_vip": {},
      "default_route_pools": [{
        "pool": {
          "namespace": "xF5XC_NAMESPACEx",
          "name": "xF5XC_ORIGIN_POOLx",
          "kind": "origin_pool"
        },
        "weight": 1,
        "priority": 1
      }],
      "client_side_defense": {
        "policy": {
          "js_insert_all_pages": {}
        }
      },
      "disable_rate_limit": {},
      "no_service_policies": {},
      "round_robin": {},
      "disable_waf": {},
      "no_challenge": {},
      "disable_bot_defense": {},
      "disable_api_definition": {},
      "disable_api_discovery": {},
      "disable_ip_reputation": {},
      "disable_malicious_user_detection": {},
      "single_lb_app": {
        "disable_discovery": {},
        "disable_ddos_detection": {},
        "disable_malicious_user_detection": {}
      },
      "disable_trust_client_ip_headers": {},
      "user_id_client_ip": {},
      "disable_threat_mesh": {},
      "l7_ddos_action_default": {},
      "system_default_timeouts": {},
      "default_sensitive_data_policy": {},
      "disable_malware_protection": {},
      "disable_api_testing": {}
    }
  }' \
  "xF5XC_API_URLx/api/config/namespaces/xF5XC_NAMESPACEx/http_loadbalancers/xF5XC_LB_NAMEx-https" \
  | jq .

200 रिस्पॉन्स पुष्टि करता है कि skeleton को पूर्ण कॉन्फ़िगरेशन के साथ पुनर्स्थापित किया गया। सर्टिफिकेट स्थिति CertificateValid रहनी चाहिए — कोई नया Let’s Encrypt प्रोविजनिंग ट्रिगर नहीं होता।

टिप्पणी

Skeleton पुनर्स्थापना। PUT पूरे ऑब्जेक्ट spec को replace करता है। Skeleton HTTPS LB ने teardown के दौरान अपनी डोमेन binding और सर्टिफिकेट बनाए रखे। यह PUT ऑरिजिन पूल रेफरेंस पुनर्स्थापित करता है और बिना नए Let’s Encrypt सर्टिफिकेट रिक्वेस्ट को ट्रिगर किए क्लाइंट-साइड डिफेंस को पुनः सक्षम करता है। HTTPS तुरंत उपलब्ध होता है।

Path B: POST के माध्यम से नया बनाएं (HTTPS LB मौजूद नहीं है)

जब कोई HTTPS LB मौजूद नहीं है (पहली बार चलाना या पूर्ण teardown के बाद), इसे POST के माध्यम से बनाएं। यह Let’s Encrypt सर्टिफिकेट प्रोविजनिंग ट्रिगर करता है, जिसमें 5–10 मिनट लग सकते हैं।

curl -s -X POST \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  -H "Content-Type: application/json" \
  -d '{
    "metadata": {
      "name": "xF5XC_LB_NAMEx-https",
      "namespace": "xF5XC_NAMESPACEx",
      "labels": {},
      "annotations": {},
      "description": "HTTPS LB with Client-Side Defense enabled (secondary, cert-dependent)",
      "disable": false
    },
    "spec": {
      "domains": ["xF5XC_DOMAINNAMEx"],
      "https_auto_cert": {
        "http_redirect": false,
        "add_hsts": false,
        "port": 443,
        "default_header": {},
        "enable_path_normalize": {},
        "no_mtls": {},
        "default_loadbalancer": {}
      },
      "advertise_on_public_default_vip": {},
      "default_route_pools": [{
        "pool": {
          "namespace": "xF5XC_NAMESPACEx",
          "name": "xF5XC_ORIGIN_POOLx",
          "kind": "origin_pool"
        },
        "weight": 1,
        "priority": 1
      }],
      "client_side_defense": {
        "policy": {
          "js_insert_all_pages": {}
        }
      },
      "disable_rate_limit": {},
      "no_service_policies": {},
      "round_robin": {},
      "disable_waf": {},
      "no_challenge": {},
      "disable_bot_defense": {},
      "disable_api_definition": {},
      "disable_api_discovery": {},
      "disable_ip_reputation": {},
      "disable_malicious_user_detection": {},
      "single_lb_app": {
        "disable_discovery": {},
        "disable_ddos_detection": {},
        "disable_malicious_user_detection": {}
      },
      "disable_trust_client_ip_headers": {},
      "user_id_client_ip": {},
      "disable_threat_mesh": {},
      "l7_ddos_action_default": {},
      "system_default_timeouts": {},
      "default_sensitive_data_policy": {},
      "disable_malware_protection": {},
      "disable_api_testing": {}
    }
  }' \
  "xF5XC_API_URLx/api/config/namespaces/xF5XC_NAMESPACEx/http_loadbalancers" \
  | jq .

200 रिस्पॉन्स पुष्टि करता है कि HTTPS लोड बैलेंसर बनाया गया। सर्टिफिकेट प्रोविजनिंग स्वचालित रूप से शुरू होती है।

सावधानी

यदि रिस्पॉन्स में "code": 8 के साथ “exhausted limits” है, तो HTTPS LB नहीं बनाया जा सकता। HTTPS LB वैकल्पिक है — डेमो HTTP LB का उपयोग करके आगे बढ़ता है। Phase 1 Evidence Summary में INFO के रूप में कोटा सीमा नोट करें।

टिप्पणी

Let’s Encrypt दर सीमाएं। एक नया HTTPS LB बनाने से Let’s Encrypt सर्टिफिकेट रिक्वेस्ट ट्रिगर होती है। Let’s Encrypt प्रति सटीक identifier set प्रति 7 दिनों में केवल 5 duplicate certificates की अनुमति देता है। यदि cert_state AutoCertDomainRateLimited दिखाता है, तो डेमो HTTP LB का उपयोग करके जारी रहता है। इस सीमा तक पहुंचने से बचने के लिए, डिफ़ॉल्ट teardown HTTPS LB को skeleton के रूप में संरक्षित करता है — चरण 4 — Teardown देखें।

साक्ष्य

पुष्टि करें कि दोनों लोड बैलेंसर CSD सक्षम के साथ मौजूद हैं। साक्ष्य के लिए हमेशा GET का उपयोग करें — POST रिस्पॉन्स क्षणिक स्थिति मान देता है जो settled कॉन्फ़िगरेशन को प्रतिबिंबित नहीं कर सकते।

HTTP LB (प्राथमिक):

curl -s \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  "xF5XC_API_URLx/api/config/namespaces/xF5XC_NAMESPACEx/http_loadbalancers/xF5XC_LB_NAMEx-http" \
  | jq '{name: .metadata.name, domains: .spec.domains, csd_enabled: (.spec.client_side_defense != null), state: .spec.state}'

फ़ील्ड	अपेक्षित	स्थिति
HTTP स्टेटस	200	यदि मिला तो PASS, 404 हो तो FAIL
name	${F5XC_LB_NAME}-http	PASS
domains	F5XC_DOMAINNAME शामिल हो	PASS
csd_enabled	true	PASS — CSD इस LB पर कॉन्फ़िगर है
state	VIRTUAL_HOST_READY या VIRTUAL_HOST_PENDING_A_RECORD	अपेक्षित — HTTP LB DNS resolve होने पर READY में बदलता है। कोई अन्य state (जैसे VIRTUAL_HOST_FAILED) FAIL है — ऑपरेटर को रिपोर्ट करें और आगे न बढ़ें

HTTPS LB (द्वितीयक):

curl -s \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  "xF5XC_API_URLx/api/config/namespaces/xF5XC_NAMESPACEx/http_loadbalancers/xF5XC_LB_NAMEx-https" \
  | jq '{name: .metadata.name, domains: .spec.domains, csd_enabled: (.spec.client_side_defense != null), state: .spec.state, cert_state: .spec.cert_state}'

फ़ील्ड	अपेक्षित	स्थिति
HTTP स्टेटस	200	यदि मिला तो PASS, 404 हो तो FAIL
name	${F5XC_LB_NAME}-https	PASS
domains	F5XC_DOMAINNAME शामिल हो	PASS
csd_enabled	true	PASS — CSD इस LB पर कॉन्फ़िगर है
creation_method	PUT (restored skeleton) या POST (नया)	INFO — PUT मौजूदा सर्टिफिकेट संरक्षित करता है
state	VIRTUAL_HOST_READY (PUT) या VIRTUAL_HOST_PENDING_A_RECORD (POST)	अपेक्षित — PUT path पहले से READY हो सकता है क्योंकि DNS skeleton से बना रहा
cert_state	CertificateValid (PUT) या PreDomainChallengePending (POST)	PUT मौजूदा cert संरक्षित करता है; POST नई प्रोविजनिंग ट्रिगर करता है

चरण 4: DNS कॉन्फ़िगर करें

लोड बैलेंसर बनाने के बाद, यह VIRTUAL_HOST_PENDING_A_RECORD स्थिति में प्रवेश करता है और स्वचालित सर्टिफिकेट PreDomainChallengePending में रहता है। LB के पूरी तरह से चालू होने से पहले दो DNS records मौजूद होने चाहिए:

1. A record — xF5XC_DOMAINNAMEx VIP IP पते की ओर इशारा करते हुए (LB रिस्पॉन्स में dns_info से)
2. ACME challenge record — TLS सर्टिफिकेट सत्यापन के लिए _acme-challenge.xF5XC_DOMAINNAMEx (F5 XC DNS के साथ managed records का उपयोग करते समय स्वचालित रूप से प्रबंधित; बाहरी DNS के लिए manual CNAME आवश्यक)

दृष्टिकोण इस बात पर निर्भर करता है कि क्या F5 XC आपके डोमेन के लिए authoritative DNS प्रदाता है।

DNS प्राधिकरण का पता लगाएं

अपने root domain के nameservers जांचें:

dig +short NS xF5XC_ROOT_DOMAINx

यदि रिस्पॉन्स में ns1.f5clouddns.com और ns2.f5clouddns.com शामिल हैं, तो F5 XC authoritative DNS प्रदाता है — विकल्प A का पालन करें। अन्यथा, बाहरी DNS के लिए विकल्प B का पालन करें।

विकल्प A: F5 XC Managed DNS

जब F5 XC authoritative DNS प्रदाता हो, तो प्लेटफ़ॉर्म स्वचालित रूप से A record और ACME challenge CNAME दोनों बना सकता है — लेकिन केवल तभी जब DNS zone में allow_http_lb_managed_records सक्षम हो।

टिप्पणी

DNS zones system नेमस्पेस में होते हैं, user नेमस्पेस में नहीं। zone का नाम root domain से मेल खाता है (जैसे, bankexample.com)।

1. जांचें कि क्या managed records सक्षम हैं:

curl -s \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  "xF5XC_API_URLx/api/config/dns/namespaces/system/dns_zones/xF5XC_ROOT_DOMAINx" \
  | jq '.spec.primary.allow_http_lb_managed_records'

यदि रिस्पॉन्स true है, तो प्लेटफ़ॉर्म लोड बैलेंसर के लिए DNS records स्वतः बनाएगा — 3. DNS resolution सत्यापित करें पर जाएं। यदि false या null है, तो अगले चरण पर जाएं।

2. Managed records सक्षम करें:

सावधानी

PUT payload में पूरा zone spec शामिल होना चाहिए — metadata और सभी मौजूदा कॉन्फ़िगरेशन फ़ील्ड। फ़ील्ड छोड़ने से वे डिफ़ॉल्ट पर रीसेट हो जाएंगे। पहले वर्तमान zone कॉन्फ़िगरेशन प्राप्त करें, फिर केवल allow_http_lb_managed_records फ़ील्ड संशोधित करें।

वर्तमान zone कॉन्फ़िगरेशन प्राप्त करें, managed records सक्षम करें और अपडेट करें:

# Get current zone config
ZONE_CONFIG=$(curl -s \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  "xF5XC_API_URLx/api/config/dns/namespaces/system/dns_zones/xF5XC_ROOT_DOMAINx")

# Update with managed records enabled
echo "$ZONE_CONFIG" \
  | jq '.spec.primary.allow_http_lb_managed_records = true' \
  | curl -s -X PUT \
    -H "Authorization: APIToken xF5XC_API_TOKENx" \
    -H "Content-Type: application/json" \
    -d @- \
    "xF5XC_API_URLx/api/config/dns/namespaces/system/dns_zones/xF5XC_ROOT_DOMAINx" \
  | jq .

सावधानी

zone spec में एक x-ves-io-managed rr_set_group होता है जिसमें platform-managed records हैं। आपके PUT payload को इस group को संरक्षित करना होगा — इसे छोड़ने से HTTP 403 “reserved for internal purposes” आता है। हमेशा पहले GET के साथ वर्तमान zone कॉन्फ़िगरेशन प्राप्त करें, केवल वही फ़ील्ड संशोधित करें जो आपको चाहिए, और पूरा spec वापस भेजें।

200 रिस्पॉन्स (खाली \{\}) पुष्टि करता है कि zone अपडेट किया गया। F5 XC zone के auto-managed record group में A record और ACME challenge record बनाएगा। यदि managed records 60 सेकंड के भीतर नहीं दिखते, तो record creation ट्रिगर करने के लिए लोड बैलेंसर को पुनः लागू करें:

LB_CONFIG=$(curl -s \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  "xF5XC_API_URLx/api/config/namespaces/xF5XC_NAMESPACEx/http_loadbalancers/xF5XC_LB_NAMEx-http")
echo "$LB_CONFIG" | curl -s -X PUT \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  -H "Content-Type: application/json" \
  -d @- \
  "xF5XC_API_URLx/api/config/namespaces/xF5XC_NAMESPACEx/http_loadbalancers/xF5XC_LB_NAMEx-http" \
  | jq .

यह GET+PUT re-apply LB कॉन्फ़िगरेशन नहीं बदलता — यह केवल प्लेटफ़ॉर्म को DNS zone का पुनः मूल्यांकन करने और managed records बनाने के लिए ट्रिगर करता है। यदि re-apply के 60 सेकंड बाद भी A record resolve नहीं होता, तो रुकें और ऑपरेटर को रिपोर्ट करें — re-apply एक से अधिक बार पुनः प्रयास न करें।

3. DNS resolution सत्यापित करें:

dig +short xF5XC_DOMAINNAMEx A

रिस्पॉन्स VIP IP पता वापस करना चाहिए। F5 XC managed zones के लिए DNS propagation आमतौर पर तत्काल होती है, लेकिन 60 सेकंड तक प्रतीक्षा करें।

संकेत

Negative DNS cache: यदि आपने record मौजूद होने से पहले डोमेन query किया था, तो आपका recursive resolver NXDOMAIN रिस्पॉन्स cache कर सकता था। Stale cache को खारिज करने के लिए authoritative nameserver या public resolver से सत्यापित करें:

dig +short xF5XC_DOMAINNAMEx A @ns1.f5clouddns.com
dig +short xF5XC_DOMAINNAMEx A @8.8.8.8

विकल्प B: बाहरी DNS प्रदाता

जब आपका डोमेन बाहरी DNS प्रदाता का उपयोग करता है, तो आपको records मैन्युअल रूप से बनाने होंगे। लोड बैलेंसर से आवश्यक मान निकालें:

curl -s \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  "xF5XC_API_URLx/api/config/namespaces/xF5XC_NAMESPACEx/http_loadbalancers/xF5XC_LB_NAMEx-http" \
  | jq '{
    vip_ip: .spec.dns_info[0].ip_address,
    acme_target: .spec.auto_cert_info.dns_records
  }'

अपने DNS प्रदाता पर ये records बनाएं:

प्रकार	नाम	मान
A	xF5XC_DOMAINNAMEx	dns_info[0].ip_address से VIP IP
CNAME	_acme-challenge.xF5XC_DOMAINNAMEx	*.autocerts.ves.volterra.io

Records बनाने के बाद, resolution सत्यापित करें:

dig +short xF5XC_DOMAINNAMEx A
dig +short _acme-challenge.xF5XC_DOMAINNAMEx CNAME

संकेत

LB के VIRTUAL_HOST_PENDING_A_RECORD से VIRTUAL_HOST_READY में बदलने के लिए A record आवश्यक है। स्वचालित TLS सर्टिफिकेट प्रोविजनिंग के लिए ACME CNAME आवश्यक है। दोनों records के बिना, LB pending state में रहेगा।

साक्ष्य

परीक्षण	कमांड	अपेक्षित	स्थिति
DNS-1: A Record	dig +short $F5XC_DOMAINNAME A	VIP IP पता मिला	IP मिले तो PASS, खाली हो तो FAIL
DNS-2: ACME CNAME	dig +short _acme-challenge.$F5XC_DOMAINNAME CNAME	*.autocerts.ves.volterra.io	CNAME मिले तो PASS
DNS authority	dig +short NS $F5XC_ROOT_DOMAIN	F5 XC या बाहरी nameservers	सूचनात्मक — विकल्प A बनाम B निर्धारित करता है

यदि DNS-1 60 सेकंड बाद खाली लौटाता है, तो समस्या निवारण — LB Stuck in VIRTUAL_HOST_PENDING_A_RECORD देखें।

चरण 5: सत्यापित करें कि CSD सक्षम है

जांचें कि टेनेंट के लिए क्लाइंट-साइड डिफेंस सक्षम है। CSD टेनेंट स्तर पर कॉन्फ़िगर किया जाता है — यदि इसे अभी तक सक्षम नहीं किया गया है, तो अपने F5 XC प्रशासक से संपर्क करें।

curl -s \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  "xF5XC_API_URLx/api/shape/csd/namespaces/xF5XC_NAMESPACEx/status" \
  | jq .

"isConfigured": true और "isEnabled": true वाला रिस्पॉन्स पुष्टि करता है कि CSD सक्रिय है।

साक्ष्य

curl -s \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  "xF5XC_API_URLx/api/shape/csd/namespaces/xF5XC_NAMESPACEx/status" \
  | jq '{configured: .isConfigured, enabled: .isEnabled}'

फ़ील्ड	अपेक्षित	स्थिति
configured	true	PASS
enabled	true	PASS
कोई भी false हो	—	FAIL — टेनेंट स्तर पर CSD सक्षम करने के लिए F5 XC प्रशासक से संपर्क करें

चरण 6: संरक्षित डोमेन पंजीकृत करें

वह root domain पंजीकृत करें जिसे CSD मॉनिटर करेगा। protected_domain फ़ील्ड eTLD+1 root domain होना चाहिए (जैसे, f5demos.com), पूर्ण FQDN नहीं।

सावधानी

संरक्षित domains टेनेंट-scoped हैं, नेमस्पेस-scoped नहीं। हेल्थचेक, ऑरिजिन पूल और लोड बैलेंसर के विपरीत, संरक्षित domains टेनेंट पर globally पंजीकृत होते हैं — API URL में नेमस्पेस एक routing पैरामीटर है, स्वामित्व सीमा नहीं। हालांकि, संरक्षित domain इस deployment से जुड़ा एक CSD कॉन्फ़िगरेशन ऑब्जेक्ट है और deployment को पूरी तरह से हटाने पर teardown के दौरान हटाया जाना चाहिए। इसे DNS zone के साथ भ्रमित न करें, जो साझा इंफ्रास्ट्रक्चर है और कभी नहीं हटाया जाना चाहिए।

जांचें कि क्या पहले से पंजीकृत है

बनाने से पहले, जांचें कि क्या डोमेन पहले से टेनेंट पर पंजीकृत है। POST के लिए 409 रिस्पॉन्स का अर्थ है डोमेन पहले से मौजूद है — यह सफलता की स्थिति है, error नहीं।

curl -s -X POST \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  -H "Content-Type: application/json" \
  -d '{
    "metadata": {
      "name": "xF5XC_DOMAINNAMEx",
      "namespace": "xF5XC_NAMESPACEx"
    },
    "spec": {
      "protected_domain": "xF5XC_ROOT_DOMAINx"
    }
  }' \
  "xF5XC_API_URLx/api/shape/csd/namespaces/xF5XC_NAMESPACEx/protected_domains" \
  | jq .

रिस्पॉन्स	अर्थ	कार्रवाई
200	डोमेन सफलतापूर्वक पंजीकृत	चरण 7 पर जाएं
409 (domain already exists)	डोमेन पहले इस टेनेंट पर पंजीकृत था	पहले से हो गया — चरण 7 पर जाएं
"code": 8 (exhausted limits)	संरक्षित domain कोटा भरा हुआ	अवरोधक — CSD के लिए संरक्षित domains आवश्यक हैं। अप्रयुक्त संरक्षित domains हटाएं या अपने प्रशासक से संपर्क करें।

साक्ष्य

POST रिस्पॉन्स स्वयं प्राथमिक साक्ष्य है — यह spec.protected_domain के साथ पंजीकृत domain ऑब्जेक्ट लौटाता है जो आपके root domain से मेल खाता है। वैकल्पिक रूप से, पुष्टि करने के लिए सभी संरक्षित domains सूचीबद्ध करें:

curl -s \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  "xF5XC_API_URLx/api/shape/csd/namespaces/xF5XC_NAMESPACEx/protected_domains" \
  | jq '.items | length'

फ़ील्ड	अपेक्षित	स्थिति
POST ने protected_domain लौटाया	F5XC_ROOT_DOMAIN से मेल खाता हो	PASS
POST ने 200 या 409 लौटाया	Domain पंजीकृत है या पहले से मौजूद है	PASS
List items count	> 0	PASS

टिप्पणी

संरक्षित domains के लिए individual GET endpoint (/protected_domains/\{name\}) उपलब्ध नहीं है। सत्यापन के लिए POST रिस्पॉन्स या list endpoint का उपयोग करें।

चरण 7: सत्यापित करें

DNS Resolution

पुष्टि करें कि A record resolve हो रहा है और ACME challenge CNAME मौजूद है:

dig +short xF5XC_DOMAINNAMEx A
dig +short _acme-challenge.xF5XC_DOMAINNAMEx CNAME

A record VIP IP पता वापस करना चाहिए। CNAME को *.autocerts.ves.volterra.io (या संबंधित autocerts target) की ओर इशारा करना चाहिए।

लोड बैलेंसर स्थिति

जांचें कि दोनों लोड बैलेंसर अपनी pending states से बाहर आ गए हैं। HTTP LB प्राथमिक जांच है — DNS resolve होने के बाद इसे VIRTUAL_HOST_READY तक पहुंचना चाहिए, बिना सर्टिफिकेट निर्भरता के। HTTPS LB सर्टिफिकेट स्थिति केवल सूचनात्मक है।

HTTP LB (प्राथमिक — आगे बढ़ने के लिए READY होना चाहिए):

curl -s \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  "xF5XC_API_URLx/api/config/namespaces/xF5XC_NAMESPACEx/http_loadbalancers/xF5XC_LB_NAMEx-http" \
  | jq '{state: .spec.state}'

फ़ील्ड	अपेक्षित	मध्यवर्ती States
state	VIRTUAL_HOST_READY	VIRTUAL_HOST_PENDING_A_RECORD — DNS कॉन्फ़िगर नहीं (चरण 4 देखें)

HTTPS LB (द्वितीयक — सूचनात्मक, प्रगति को अवरुद्ध नहीं करता):

curl -s \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  "xF5XC_API_URLx/api/config/namespaces/xF5XC_NAMESPACEx/http_loadbalancers/xF5XC_LB_NAMEx-https" \
  | jq '{state: .spec.state, cert_state: .spec.cert_state}'

फ़ील्ड	अपेक्षित	मध्यवर्ती States
state	VIRTUAL_HOST_READY	VIRTUAL_HOST_PENDING_A_RECORD — DNS कॉन्फ़िगर नहीं; VIRTUAL_HOST_DNS_A_RECORD_ADDED — A record मिला, cert की प्रतीक्षा
cert_state	CertificateValid	PreDomainChallengePending — ACME CNAME की प्रतीक्षा; DomainChallengeStarted — ACME challenge प्रगति में; AutoCertDomainRateLimited — Let’s Encrypt दर सीमा पहुंची (डेमो एनवायरनमेंट में अपेक्षित, HTTP LB प्रभावित नहीं होता)

टिप्पणी

DNS records बनने के बाद सर्टिफिकेट प्रोविजनिंग में 5–10 मिनट लग सकते हैं। यदि cert_state AutoCertDomainRateLimited दिखाता है, तो यह डेमो एनवायरनमेंट में अपेक्षित है जहां इंफ्रास्ट्रक्चर बार-बार बनाया और हटाया जाता है। HTTP LB अप्रभावित है — http:// URLs का उपयोग करके डेमो के साथ आगे बढ़ें।

JS कॉन्फ़िगरेशन

curl -s \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  "xF5XC_API_URLx/api/shape/csd/namespaces/xF5XC_NAMESPACEx/js_configuration" \
  | jq .

रिस्पॉन्स में एक scriptTag फ़ील्ड होता है जिसमें पूरा HTML <script> tag होता है जिसे लोड बैलेंसर page responses में inject करता है।

Detected Domains

curl -s \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  "xF5XC_API_URLx/api/shape/csd/namespaces/xF5XC_NAMESPACEx/detected_domains" \
  | jq '{summary: .domain_summary, domains: .domains_list}'

Detected Scripts

scripts endpoint के लिए epoch timestamps (Unix epoch के बाद से सेकंड) का उपयोग करके एक समय सीमा आवश्यक है। नीचे दिया गया उदाहरण पिछले 7 दिनों की query करता है।

NOW=$(date +%s)
START=$(( NOW - 604800 ))
curl -s -X POST \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  -H "Content-Type: application/json" \
  -d "{\"startTime\": \"$START\", \"endTime\": \"$NOW\"}" \
  "xF5XC_API_URLx/api/shape/csd/namespaces/xF5XC_NAMESPACEx/scripts" \
  | jq '[.scripts[]? | {script_name: .script_name, risk_level: .risk_level}]'

Form Fields

form fields endpoint के लिए epoch timestamps का उपयोग करके एक समय सीमा आवश्यक है, जो query parameters के रूप में पास की जाती है।

NOW=$(date +%s)
START=$(( NOW - 604800 ))
curl -s \
  -H "Authorization: APIToken xF5XC_API_TOKENx" \
  "xF5XC_API_URLx/api/shape/csd/namespaces/xF5XC_NAMESPACEx/formFields?startTime=$START&endTime=$NOW" \
  | jq '.form_fields'

चरण 1 साक्ष्य सारांश

सभी सत्यापन जांच पूरी करने के बाद, AI सहायक को एक consolidated status table प्रस्तुत करना चाहिए:

परीक्षण ID	जांच	अपेक्षित	आवश्यक	स्थिति
DNS-1	A Record resolve होता है	VIP IP पता मिला	हाँ	PASS / FAIL
DNS-2	ACME CNAME मौजूद है	*.autocerts.ves.volterra.io	नहीं	PASS / PENDING
LB-1	HTTP LB state	VIRTUAL_HOST_READY	हाँ	PASS / PENDING
LB-2	HTTPS LB state	VIRTUAL_HOST_READY	नहीं	PASS / PENDING / INFO
TLS-1	सर्टिफिकेट state	CertificateValid	नहीं	PASS / PENDING / INFO
CSD-1	JS कॉन्फ़िगरेशन	scriptTag मौजूद	हाँ	PASS / FAIL
CSD-2	CSD स्थिति	isEnabled: true	हाँ	PASS / FAIL
CSD-3	संरक्षित domain	Domain पंजीकृत	हाँ	PASS / FAIL

टिप्पणी

चरण 2 HTTP LB का उपयोग करता है। HTTPS वैकल्पिक है — यदि TLS-1 AutoCertDomainRateLimited दिखाता है या LB-2 PENDING रहता है, तो डेमो http:// URLs का उपयोग करके सामान्य रूप से आगे बढ़ता है। चरण 2 पर आगे बढ़ने से पहले केवल DNS-1, LB-1, CSD-1, CSD-2 और CSD-3 का PASS होना आवश्यक है।

यदि LB-1 PENDING दिखाता है, तो 4 iterations तक (कुल 2 मिनट) हर 30 सेकंड में poll करें। यदि 4 iterations के बाद भी LB-1 VIRTUAL_HOST_READY नहीं है, तो dig से DNS resolution जांचें और ऑपरेटर को रिपोर्ट करें — LB-1 READY होने तक आगे न बढ़ें। LB-2 और TLS-1 के लिए, 10 iterations तक (10 मिनट) हर 60 सेकंड में poll करें। यदि 10 iterations के बाद भी मध्यवर्ती state में हैं, तो वर्तमान state INFO के रूप में रिकॉर्ड करें और आगे बढ़ें — ये सूचनात्मक हैं और डेमो प्रगति को अवरुद्ध नहीं करते।

टिप्पणी

LB रिस्पॉन्स में dns_info फ़ील्ड खाली ([]) हो सकता है, भले ही DNS सही ढंग से resolve होता हो — यह clean recreation के बाद होता है। VIP पते के लिए dns_info पर निर्भर रहने के बजाय हमेशा dig से DNS resolution सत्यापित करें।

---

चरण 1 पूरा। आक्रमण सिमुलेशन चलाने के लिए चरण 2 — आक्रमण पर आगे बढ़ें।