एसएसएल हैंडशेक की कोशिशें - खराब क्लाइंट सर्टिफ़िकेट

आपको Apigee Edge दस्तावेज़ दिख रहा है.
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है इस पेज पर जाएं Apigee X दस्तावेज़.
जानकारी

समस्या का ब्यौरा

क्लाइंट ऐप्लिकेशन को 503 का HTTP स्थिति कोड एपीआई अनुरोध के रिस्पॉन्स के तौर पर, "सेवा उपलब्ध नहीं है" मैसेज. यूज़र इंटरफ़ेस (यूआई) ट्रेस में, आपको error.cause की सुविधा दिखेगी क्या यह लक्ष्य अनुरोध के फ़्लो में Received fatal alert: bad_certificate है देखें.

अगर आपके पास मैसेज प्रोसेसर के लॉग का ऐक्सेस है, तो तब आपको गड़बड़ी का मैसेज Received fatal alert: bad_certificate के तौर पर दिखेगा देखें. यह गड़बड़ी एसएसएल हैंडशेक के दौरान दिखती है 2-तरफ़ा TLS सेटअप में प्रोसेस को पूरा करता है.

गड़बड़ी संदेश

क्लाइंट ऐप्लिकेशन को यह रिस्पॉन्स कोड मिलता है:

HTTP/1.1 503 Service Unavailable

इसके अलावा, आपको गड़बड़ी का यह मैसेज भी दिख सकता है:

{
 "fault": {
    "faultstring":"The Service is temporarily unavailable",
    "detail":{
        "errorcode":"messaging.adaptors.http.flow.ServiceUnavailable"
    }
 }
}

निजी क्लाउड उपयोगकर्ताओं को किसी खास एपीआई अनुरोध के लिए नीचे दी गई गड़बड़ी दिखेगी मैसेज प्रोसेसर के लॉग /opt/apigee/var/log/edge-message-processor/system.log में:

2017-10-23 05:28:57,813 org:org-name env:env-name api:apiproxy-name rev:revision-number messageid:message_id NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() : SSLClientChannel[C:IP address:port # Remote host:IP address:port #]@65461 useCount=1 bytesRead=0 bytesWritten=0 age=529ms lastIO=529ms handshake failed, message: Received fatal alert: bad_certificate

संभावित वजहें

इस समस्या की ये वजहें हो सकती हैं:

Cause जानकारी समस्या हल करने के निर्देश इनके लिए लागू होते हैं
कोई क्लाइंट सर्टिफ़िकेट नहीं है टारगेट सर्वर के टारगेट एंडपॉइंट में इस्तेमाल किए गए कीस्टोर में, कोई क्लाइंट सर्टिफ़िकेट नहीं है. Edge के निजी और सार्वजनिक क्लाउड उपयोगकर्ता
सर्टिफ़िकेट देने वाली संस्था (सर्टिफ़िकेट अथॉरिटी) मेल नहीं खाती लीफ़ सर्टिफ़िकेट की सर्टिफ़िकेट देने वाली संस्था (सर्टिफ़िकेट चेन में पहला सर्टिफ़िकेट) में मौजूद 'सर्टिफ़िकेट अथॉरिटी' की जानकारी बैकएंड सर्वर के ज़रिए स्वीकृत किसी भी प्रमाणपत्र प्राधिकरण से मेल नहीं खाती. Edge के निजी और सार्वजनिक क्लाउड उपयोगकर्ता

डायग्नोसिस के सामान्य चरण

  1. Edge के यूज़र इंटरफ़ेस (यूआई) में ट्रेस की सुविधा चालू करें, एपीआई कॉल करें, और समस्या के बारे में जानें.
  2. यूज़र इंटरफ़ेस (यूआई) ट्रेस के नतीजों में, हर चरण में जाएं और तय करें कि कोई गड़बड़ी हुई. गड़बड़ी, टारगेट अनुरोध के फ़्लो में हुई होगी.
  3. गड़बड़ी दिखाने वाले फ़्लो की जांच करें. आपको गड़बड़ी को दिखाए गए तरीके से देखना चाहिए नीचे उदाहरण ट्रेस में:
    अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

    alt_टेक्स्ट

  4. जैसा कि ऊपर दिए गए स्क्रीनशॉट में दिखाया गया है, उसमें error.cause की वैल्यू "गंभीर चेतावनी: Bad_certificate".
  5. अगर आप निजी Cloud उपयोगकर्ता हैं, तो नीचे दिए गए निर्देशों का पालन करें:
    1. एपीआई अनुरोध पूरा न होने पर, उसके लिए मैसेज आईडी मिल सकता है. इसके लिए, गड़बड़ी के हेडर "X-Apigee.Message-ID" की वैल्यू ट्रेस में AX के ज़रिए बताए गए फ़ेज़ में देखें.
    2. मैसेज प्रोसेसर लॉग में, इस मैसेज आईडी को खोजें /opt/apigee/var/log/edge-message-processor/system.log और तय करें अगर आपको गड़बड़ी के बारे में कोई और जानकारी मिल सकती है, तो:
      2017-10-23 05:28:57,813 org:org-name env:env-name api:apiproxy-name
      rev:revision-number messageid:message_id NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() :
      SSLClientChannel[C:IP address:port # Remote host:IP address:port #]@65461 useCount=1
      bytesRead=0 bytesWritten=0 age=529ms lastIO=529ms handshake failed, message: Received fatal alert: bad_certificate
      2017-10-23 05:28:57,813 org:org-name env:env-name api:apiproxy-name
      rev:revision-number messageid:message_id NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() : SSLInfo:
      KeyStore:java.security.KeyStore@52de60d9 KeyAlias:KeyAlias TrustStore:java.security.KeyStore@6ec45759
      2017-10-23 05:28:57,814 org:org-name env:env-name api:apiproxy-name
      rev:revision-number messageid:message_id NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onException() :
      RequestWriteListener.onException(HTTPRequest@6071a73d)
      javax.net.ssl.SSLException: Received fatal alert: bad_certificate
      at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) ~[na:1.8.0_101]
      at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666) ~[na:1.8.0_101]
      at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1634) ~[na:1.8.0_101]
      at sun.security.ssl.SSLEngineImpl.recvAlert(SSLEngineImpl.java:1800) ~[na:1.8.0_101]
      at com.apigee.nio.NIOSelector$SelectedIterator.findNext(NIOSelector.java:496) [nio-1.0.0.jar:na]
      at com.apigee.nio.util.NonNullIterator.computeNext(NonNullIterator.java:21) [nio-1.0.0.jar:na]
      at com.apigee.nio.util.AbstractIterator.hasNext(AbstractIterator.java:47) [nio-1.0.0.jar:na]
      at com.apigee.nio.NIOSelector$2.findNext(NIOSelector.java:312) [nio-1.0.0.jar:na]
      at com.apigee.nio.NIOSelector$2.findNext(NIOSelector.java:302) [nio-1.0.0.jar:na]
      at com.apigee.nio.util.NonNullIterator.computeNext(NonNullIterator.java:21) [nio-1.0.0.jar:na]
      at com.apigee.nio.util.AbstractIterator.hasNext(AbstractIterator.java:47) [nio-1.0.0.jar:na]
      at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:59) [nio-1.0.0.jar:na]
      

      मैसेज प्रोसेसर के लॉग में गड़बड़ी के लिए स्टैक ट्रेस मौजूद था Received fatal alert: bad_certificate, लेकिन इसमें शामिल नहीं है के पास इस समस्या की वजह बताने वाली कोई और जानकारी हो.

  6. इस समस्या की आगे जांच करने के लिए, आपको इनका इस्तेमाल करके टीसीपी/आईपी पैकेट को कैप्चर करना होगा tcpdump टूल.
    1. अगर आप निजी क्लाउड उपयोगकर्ता हैं, तो बैकएंड सर्वर या मैसेज प्रोसेसर पर टीसीपी/आईपी पैकेट. बेहतर होगा कि उन्हें बैकएंड सर्वर पर कैप्चर किया जाए, क्योंकि पैकेट डिक्रिप्ट किए जाते हैं भी डाउनलोड कर सकता है.
    2. अगर आप सार्वजनिक क्लाउड उपयोगकर्ता हैं, तो टीसीपी/आईपी को कैप्चर करें पर पैकेट मौजूद होते हैं.
    3. जब आप यह तय कर लें कि आपको टीसीपी/आईपी पैकेट कहां से कैप्चर करने हैं, तो tcpdump के नीचे इस निर्देश का इस्तेमाल करके, टीसीपी/आईपी पैकेट कैप्चर किए जा सकते हैं.
    4. tcpdump -i any -s 0 host <IP address> -w <File name>

      यदि आप Message प्रोसेसर पर टीसीपी/आईपी पैकेट ले रहे हैं, तो tcpdump निर्देश में बैकएंड सर्वर का सार्वजनिक आईपी पता.

      अगर बैकएंड सर्वर/मैसेज प्रोसेसर के लिए एक से ज़्यादा आईपी पते हैं, तो तो आपको किसी दूसरे tcpdump कमांड का इस्तेमाल करना होगा. इससे संदर्भ लें tcpdump इस टूल और इस निर्देश के अन्य वैरिएंट के बारे में ज़्यादा जानकारी पाने के लिए.

  7. Wireshark टूल या ऐसे ही दूसरे टूल का इस्तेमाल करके, टीसीपी/आईपी पैकेट का विश्लेषण करें.

यहां Wireshark टूल का इस्तेमाल करके, टीसीपी/आईपी पैकेट के सैंपल डेटा का विश्लेषण किया गया है:

alt_टेक्स्ट

  1. ऊपर दिए गए tcpdump में मैसेज #4 से पता चलता है कि मैसेज प्रोसेसर (सोर्स) बैकएंड सर्वर (डेस्टिनेशन) पर "क्लाइंट हैलो" मैसेज भेजा गया.
  2. मैसेज #5 से पता चलता है कि बैकएंड सर्वर, क्लाइंट के नमस्ते मैसेज को स्वीकार करता है मैसेज प्रोसेसर से मिल रही है.
  3. बैकएंड सर्वर, "सर्वर हेलो" भेजता है अपने प्रमाणपत्र के साथ संदेश भेजें, और फिर क्लाइंट से मैसेज #7 में उसका सर्टिफ़िकेट भेजने का अनुरोध करता है.
  4. मैसेज प्रोसेसर, सर्टिफ़िकेट की पुष्टि करता है और मैसेज #8 में बैकएंड सर्वर का Serverhello मैसेज.
  5. मैसेज प्रोसेसर, मैसेज #9 में बैकएंड सर्वर को अपना सर्टिफ़िकेट भेजता है.
  6. बैकएंड सर्वर, मैसेज प्रोसेसर की रसीद स्वीकार करता है मैसेज #11 में सर्टिफ़िकेट.
  7. हालांकि, यह तुरंत मैसेज प्रोसेसर (मैसेज #12). इससे पता चलता है कि सर्टिफ़िकेट देने वाली कंपनी मैसेज प्रोसेसर खराब था. इसलिए, सर्टिफ़िकेट की पुष्टि नहीं की जा सकी भी डाउनलोड कर सकता है. इस वजह से, एसएसएल हैंडशेक नहीं हो सका और कनेक्शन बंद हो जाएगा.


    alt_टेक्स्ट

  8. मैसेज प्रोसेसर से मिले सर्टिफ़िकेट के कॉन्टेंट की जांच करने के लिए, मैसेज #9 को देखते हैं:


    alt_टेक्स्ट

  9. जैसा कि देखा जा सकता है, बैकएंड सर्वर को क्लाइंट से कोई सर्टिफ़िकेट नहीं मिला (सर्टिफ़िकेट की लंबाई: 0). इसलिए, बैकएंड सर्वर गंभीर चेतावनी: खराब प्रमाणपत्र भेजता है.
  10. आम तौर पर, ऐसा तब होता है, जब क्लाइंट यानी मैसेज प्रोसेसर (Java पर आधारित प्रोसेस):
    1. उसके KeyStore में कोई क्लाइंट सर्टिफ़िकेट नहीं है या;
    2. यह क्लाइंट सर्टिफ़िकेट नहीं भेज सका. यह समस्या तब हो सकती है, जब ऐसा प्रमाणपत्र जो बैकएंड सर्वर के स्वीकार्य प्रमाणपत्र प्राधिकरणों में से किसी एक द्वारा जारी किया गया हो. इसका मतलब है कि अगर क्लाइंट के लीफ़ सर्टिफ़िकेट की सर्टिफ़िकेट अथॉरिटी (जैसे, चेन का पहला सर्टिफ़िकेट) किसी भी बैकएंड सर्वर के स्वीकार की जाने वाली सर्टिफ़िकेट अथॉरिटी का अनुरोध करता है, तो मैसेज प्रोसेसर सर्टिफ़िकेट नहीं भेजेगा.

आइए, इनमें से हर एक वजह को अलग से देखते हैं. इसकी जानकारी नीचे दी गई है.

वजह: क्लाइंट सर्टिफ़िकेट नहीं है

संक्रमण की जांच

अगर एसएसएल की जानकारी वाले सेक्शन में बताए गए कीस्टोर में कोई सर्टिफ़िकेट नहीं है टारगेट एंडपॉइंट या टारगेट एंडपॉइंट में इस्तेमाल किए गए टारगेट सर्वर का डेटा शामिल होता है. तो यह गड़बड़ी की वजह है.

यह वजह है या नहीं, इसका पता लगाने के लिए यहां दिया गया तरीका अपनाएं:

  1. टारगेट एंडपॉइंट या टारगेट सर्वर में इस्तेमाल किए जा रहे कीस्टोर को पता करना नीचे दिए गए चरणों का इस्तेमाल करके खास एपीआई प्रॉक्सी के लिए:
    1. कीस्टोर एलिमेंट से, कीस्टोर रेफ़रंस नाम पाएं टारगेट एंडपॉइंट या टारगेट सर्वर के SSLInfo सेक्शन में.

      टारगेट एंडपॉइंट कॉन्फ़िगरेशन में, SSLInfo सेक्शन का सैंपल देखें:

      <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <KeyStore>ref://myKeystoreRef</KeyStore>
        <KeyAlias>myKey</KeyAlias>
        <TrustStore>ref://myTrustStoreRef</TrustStore>
      </SSLInfo>
    2. ऊपर दिए गए उदाहरण में, कीस्टोर रेफ़रंस का नाम "myKeystoreRef" है.
    3. Edge के यूज़र इंटरफ़ेस (यूआई) पर जाएं और एपीआई प्रॉक्सी -> को चुनें एनवायरमेंट से जुड़े कॉन्फ़िगरेशन.

      रेफ़रंस टैब चुनें और कीस्टोर रेफ़रंस नाम खोजें. किसी कीस्टोर रेफ़रंस फ़ाइल के लिए, रेफ़रंस कॉलम में दिया गया नाम नोट कर लें. यह आपके कीस्टोर का नाम होगा.


      alt_टेक्स्ट

    4. ऊपर के उदाहरण में देखा जा सकता है कि myKeystoreRef में रेफ़रंस है से "myKeystore" पर सेट करना है. इसलिए, कीस्टोर का नाम myKeystore है.
  2. देखें कि इस कीस्टोर में Edge यूज़र इंटरफ़ेस (यूआई) या कीस्टोर एपीआई के लिए सर्टिफ़िकेट की सूची बनाना.
  3. अगर कीस्टोर में प्रमाणपत्र हैं, तो यहां जाएं वजह: सर्टिफ़िकेट देने वाली संस्था मेल नहीं खाती.
  4. अगर कीस्टोर में कोई सर्टिफ़िकेट नहीं है, तो क्लाइंट प्रमाणपत्र, संदेश प्रोसेसर के ज़रिए नहीं भेजा जाता है.

रिज़ॉल्यूशन

  1. पक्का करें कि मैसेज प्रोसेसर में, सही कीस्टोर पर क्लाइंट सर्टिफ़िकेट की सही चेन अपलोड की गई हो.

वजह: सर्टिफ़िकेट देने वाली संस्था मेल नहीं खा रही है

आम तौर पर, जब सर्वर क्लाइंट से सर्टिफ़िकेट भेजने का अनुरोध करता है, तो वह यह, सर्टिफ़िकेट जारी करने वाली मान्य इकाइयों या सर्टिफ़िकेट जारी करने वाली इकाइयों के बारे में बताता है. अगर लीफ़ सर्टिफ़िकेट जारी करने वाला/सर्टिफ़िकेट देने वाली संस्था का है (जैसे, पहले सर्टिफ़िकेट की चेन में मौजूद सर्टिफ़िकेट) के लिए, मैसेज प्रोसेसर के कीस्टोर में ऐसा किया जाता है बैकएंड सर्वर द्वारा स्वीकृत किसी भी प्रमाणपत्र प्राधिकरण से मेल नहीं खाता, तो मैसेज प्रोसेसर (जो Java पर आधारित प्रोसेस है) बैकएंड सर्वर को प्रमाणपत्र न भेजें.

यहां दिया गया तरीका अपनाकर पता करें कि ऐसा ही हुआ है या नहीं:

  1. कीस्टोर एपीआई के लिए सर्टिफ़िकेट की सूची बनाना.
  2. ऊपर चरण #1 में मिले हर सर्टिफ़िकेट की जानकारी पाने के लिए, कीस्टोर एपीआई के लिए सर्टिफ़िकेट पाएं.
  3. कीस्टोर में स्टोर किए गए लीफ़ सर्टिफ़िकेट (जैसे, सर्टिफ़िकेट चेन का पहला सर्टिफ़िकेट) को जारी करने वाले व्यक्ति को नोट करें.

    लीफ़ सर्टिफ़िकेट का सैंपल

    {
      "certInfo" : [ {
        "basicConstraints" : "CA:FALSE",
        "expiryDate" : 1578889324000,
        "isValid" : "Yes",
        "issuer" : "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com",
        "publicKey" : "RSA Public Key, 2048 bits",
        "serialNumber" : "65:00:00:00:d2:3e:12:d8:56:fa:e2:a9:69:00:06:00:00:00:d2",
        "sigAlgName" : "SHA256withRSA",
        "subject" : "CN=nonprod-api.mycompany.com, OU=ITS, O=MyCompany, L=MELBOURNE, ST=VIC, C=AU",
        "subjectAlternativeNames" : [ ],
        "validFrom" : 1484281324000,
        "version" : 3
      } ],
      "certName" : "nonprod-api.mycompany.com.key.pem-cert"
    }
    

    ऊपर दिए गए उदाहरण में, सर्टिफ़िकेट देने वाली संस्था/सर्टिफ़िकेट देने वाली संस्था "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com"

  4. इनमें से किसी एक तकनीक का इस्तेमाल करके, बैकएंड सर्वर जारी करने वालों या सर्टिफ़िकेट देने वाली संस्थाओं की स्वीकार की गई सूची तय करें:

    तकनीक #1: नीचे दिए गए Openएसएसएल कमांड का इस्तेमाल करें:

    openssl s_client -host <backend server host name> -port <Backend port#> -cert <Client Certificate> -key <Client Private Key>
    

    "स्वीकार किए जाने वाले क्लाइंट सर्टिफ़िकेट के सीए नाम" टाइटल वाला सेक्शन देखें इस निर्देश के आउटपुट में, जैसा कि नीचे दिखाया गया है:

    Acceptable client certificate CA names
    /C=AU/ST=VIC/L=MELBOURNE/O=MyCompany/OU=ITS/CN=nonprod-api.mycompany.com
    /C=AU/ST=VIC/L=MELBOURNE/O=MyCompany/OU=ITS/CN=nonprod-api.mycompany.com
    

    तकनीक #2: Certificate Request पैकेट को टीसीपी/आईपी पैकेट, जहां बैकएंड सर्वर क्लाइंट से सर्टिफ़िकेट भेजने का अनुरोध करता है:

    ऊपर दिखाए गए सैंपल टीसीपी/आईपी पैकेट में, Certificate Request पैकेट में मैसेज #7 है. "अलग-अलग नाम" सेक्शन देखें, इसमें बैकएंड सर्वर की मान्य सर्टिफ़िकेट देने वाली संस्थाएं शामिल होती हैं.

    alt_टेक्स्ट

  5. पुष्टि करें कि चरण#3 में मिला सर्टिफ़िकेट अथॉरिटी, सूची से मेल खाती है जारी करने वाले या सर्टिफ़िकेट देने वाली संस्थाओं के बारे में बताएं. अगर यह मेल नहीं खाता है, तो मैसेज प्रोसेसर, क्लाइंट सर्टिफ़िकेट नहीं भेजेगा से लिंक करना है.

    ऊपर दिए गए उदाहरण में देखा जा सकता है कि क्लाइंट का लीफ़ सर्टिफ़िकेट जारी करने वाली कंपनी के किसी भी बैकएंड सर्वर से मेल नहीं खाता सर्टिफ़िकेट देने वाली ऐसी संस्थाएं जिन्हें स्वीकार किया गया है. इसलिए, मैसेज प्रोसेसर बैकएंड सर्वर पर क्लाइंट प्रमाणपत्र भेजें. इसकी वजह से, एसएसएल हैंडशेक काम नहीं करता और बैकएंड सर्वर "Fatal alert: bad_certificate" भेजता है दिखाई देगा.

रिज़ॉल्यूशन

  1. पक्का करें कि इसे जारी करने वाले/सर्टिफ़िकेट देने वाली संस्था या निकाय के पास दिया गया सर्टिफ़िकेट किसी ऐसे सर्टिफ़िकेट से मेल खाता हो क्लाइंट लीफ़ सर्टिफ़िकेट (पहला सर्टिफ़िकेट) को जारी करने वाली संस्था/सर्टिफ़िकेट देने वाली संस्था चेन में) को बैकएंड सर्वर के Truststore में स्टोर किया जाता है.
  2. इस प्लेबुक में बताए गए उदाहरण में, जारी करने वाले के पास मौजूद सर्टिफ़िकेट "issuer" : "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com" को समस्या के समाधान के लिए बैकएंड सर्वर के Truststore में जोड़ा गया.

अगर इसके बाद भी समस्या बनी रहती है, तो गड़बड़ी की जानकारी ज़रूर इकट्ठा करें पर जाएं.

गड़बड़ी की जानकारी ज़रूर इकट्ठा करें

यदि ऊपर दिए गए निर्देशों का पालन करने के बाद भी समस्या बनी रहती है, तो कृपया गड़बड़ी की यह जानकारी इकट्ठा करें. संपर्क करें और उनसे शेयर करें Apigee Edge की सहायता टीम:

  1. अगर आप Public Cloud उपयोगकर्ता हैं, तो यह जानकारी दें:
    1. संगठन का नाम
    2. एनवायरमेंट का नाम
    3. एपीआई प्रॉक्सी का नाम
    4. गड़बड़ी को ठीक करने के लिए curl कमांड पूरा करें
    5. गड़बड़ी दिखाने वाली ट्रेस फ़ाइल
    6. बैकएंड सर्वर पर कैप्चर किए गए टीसीपी/आईपी पैकेट
  2. अगर आप प्राइवेट क्लाउड उपयोगकर्ता हैं, तो यह जानकारी दें:
    1. पूरा गड़बड़ी का मैसेज दिखा
    2. एपीआई प्रॉक्सी बंडल
    3. गड़बड़ी दिखाने वाली ट्रेस फ़ाइल
    4. मैसेज प्रोसेसर के लॉग /opt/apigee/var/log/edge-message-processor/logs/system.log
    5. बैकएंड सर्वर या मैसेज प्रोसेसर पर कैप्चर किए गए टीसीपी/आईपी पैकेट.
    6. कीस्टोर एपीआई के लिए सर्टिफ़िकेट पाएं का आउटपुट.
  3. इस प्लेबुक में दिखाए गए सेक्शन और किसी अन्य सेक्शन के बारे में जानकारी के बारे में ज़्यादा जानकारी मिलेगी. इससे हमें इस समस्या को तेज़ी से हल करने में मदद मिलेगी.