AccessControl नीति के मुताबिक रनटाइम की गड़बड़ी से जुड़ी समस्या हल करना

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

IPDeniedAccess

गड़बड़ी का कोड

accesscontrol.IPDeniedAccess

गड़बड़ी के जवाब का मुख्य हिस्सा

{
    "fault": {
        "faultstring": "Access Denied for client ip : client_IP",
        "detail": {
            "errorcode": "accesscontrol.IPDeniedAccess"
        }
    }
}

गड़बड़ी के मैसेज का उदाहरण

{
    "fault": {
        "faultstring": "Access Denied for client ip : 104.132.196.83",
        "detail": {
            "errorcode": "accesscontrol.IPDeniedAccess"
        }
    }
}

वजह

यह गड़बड़ी तब होती है, जब क्लाइंट का आईपी पता या एपीआई अनुरोध के तहत पास किया गया कोई आईपी पता, ऐक्सेस कंट्रोल की नीति के <MatchRule> एलिमेंट में मौजूद <SourceAddress> एलिमेंट में बताए गए किसी भी आईपी पते से मेल खाता हो और <MatchRule> एलिमेंट का action एट्रिब्यूट DENY पर सेट हो.

उदाहरण के लिए, मान लें कि <SourceAddress> के बारे में नीचे बताया गया है:

<SourceAddress mask="32">104.132.196.83</SourceAddress>

अगर ऊपर दिया गया आईपी पता, क्लाइंट सिस्टम के आईपी पते (जिसे वैरिएबल proxy.client.ip से दिखाया जाता है) या एपीआई अनुरोध के तौर पर पास किए गए किसी भी आईपी पते से मैच करता है, तो गड़बड़ी होगी.

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

  1. उन आईपी पतों की पहचान करें जिन्हें एपीआई के किसी खास अनुरोध को ऐक्सेस नहीं किया जा सकता. आपको यह जानकारी, गड़बड़ी के रिस्पॉन्स के faultstring एलिमेंट में मिलेगी.

    उदाहरण के लिए, यहां दिए गए faultstring में, आईपी पता 104.132.196.83: है

    "faultstring": "Access Denied for client ip : 104.132.196.83"

  2. फ़ेल हो चुके एपीआई प्रॉक्सी में, ऐक्सेस कंट्रोल की सभी नीतियों की जांच करें. साथ ही, उस नीति का पता लगाएं जिसमें <SourceAddress> एलिमेंट में बताए गए आईपी पते, faultstring में बताए गए आईपी पतों से मेल खाते हों (ऊपर दिया गया पहला चरण).

    उदाहरण के लिए, इस नीति में <SourceAddress> आईपी को 104.132.196.83, के तौर पर बताया गया है, जो faultstring में मौजूद आईपी पते से मेल खाता है:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <AccessControl async="false" continueOnError="false" enabled="true" name="Access-Control">
    <DisplayName>Access-Control</DisplayName>
    <Properties/>
    <IPRules noRuleMatchAction="ALLOW">
        <MatchRule action="DENY">
            <SourceAddress mask="32">104.132.196.83</SourceAddress>
        </MatchRule>
    </IPRules>
    </AccessControl>

  3. वे आईपी पते पता करें जिनसे एपीआई अनुरोध किया गया था. ऐसा कई तरीकों से किया जा सकता है:

    1. यूज़र इंटरफ़ेस (यूआई) ट्रेस का इस्तेमाल करना

      1. पूरे न हो पाने वाले एपीआई अनुरोध के लिए, ट्रेस को कैप्चर करें.
      2. दाईं ओर दिए गए पैनल से, ऐक्सेस कंट्रोल की वह नीति चुनें जो पूरी नहीं हो सकी.

      3. वैरिएबल proxy.client.ip की वैल्यू की जांच करें, जैसा कि सैंपल ट्रेस के इस स्क्रीनशॉट में दिखाया गया है.

      4. अगर proxy.client.ip, सूची में नहीं है, तो X-फ़ॉरवर्ड किया गया-For या True-Client-IP मैसेज हेडर.

    2. कस्टम रिपोर्ट का इस्तेमाल करना

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

      कस्टम रिपोर्ट बनाने का तरीका जानने के लिए, कस्टम रिपोर्ट बनाना और उन्हें मैनेज करना लेख पढ़ें. कस्टम रिपोर्ट में, इन्हें चुनें:

      1. मेट्रिक के तौर पर ट्रैफ़िक का योग, और

      2. डाइमेंशन के तौर पर, प्रॉक्सी, रिस्पॉन्स स्टेटस कोड, प्रॉक्सी क्लाइंट आईपी और X-forwarded-For.

      इससे आपको वह क्लाइंट आईपी या आईपी पता पता करने में मदद मिलेगी जिसकी वजह से गड़बड़ी हुई.

  4. अगर क्लाइंट का आईपी पता (proxy.client.ip वैरिएबल से दिखाया जाता है) या एपीआई अनुरोध के तहत पास किया गया कोई आईपी पता, ऐक्सेस कंट्रोल नीति के <MatchRule> एलिमेंट में मौजूद <SourceAddress> एलिमेंट में बताए गए आईपी पते(पतों) से मेल खाता है, तो यहां action एट्रिब्यूट को DENY पर सेट किया गया है. अगर ऐसा है, तो गड़बड़ी की वजह यही है.

    ऊपर दिए गए उदाहरण में, रेफ़रंस वैरिएबल proxy.client.ip (जैसा कि ऊपर ट्रेस के स्क्रीनशॉट में दिखाया गया है) में सेट की गई वैल्यू, ऐक्सेस कंट्रोल नीति के <SourceAddress> एलिमेंट में बताए गए आईपी पते से मेल खाती है. इससे गड़बड़ी का रिस्पॉन्स ट्रिगर होता है:

    "faultstring": "Access Denied for client ip : 104.132.196.83"

रिज़ॉल्यूशन

अगर ऐक्सेस कंट्रोल की नीति का मकसद, faultstring में बताए गए खास आईपी पतों से आने वाले एपीआई अनुरोधों का ऐक्सेस अस्वीकार करना है, तो गड़बड़ी का मैसेज दिख सकता है. इस मामले में, आपको कुछ और करने की ज़रूरत नहीं है.

हालांकि, अगर आपको लगता है कि किसी खास आईपी पते (पतों) को, उस एपीआई प्रॉक्सी के लिए एपीआई अनुरोधों का ऐक्सेस दिया जा सकता है, तो उन आईपी पतों को ऐक्सेस करने की अनुमति देने के लिए, ऐक्सेस कंट्रोल की नीति में बदलाव करें. अगर आप किसी आईपी पते(पतों) को ऐक्सेस करने की मंज़ूरी नहीं देना चाहते, तो आपके पास एपीआई प्रॉक्सी से ऐक्सेस कंट्रोल की नीति को हटाने का विकल्प भी होता है.

यहां एक उदाहरण दिया गया है, जिसमें सिर्फ़ किसी खास आईपी पते 104.132.196.83 को ऐक्सेस देने और बाकी आईपी पते को ऐक्सेस न देने का तरीका बताया गया है:

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "DENY">
    <MatchRule action = "ALLOW">
      <SourceAddress mask="32">104.132.196.83</SourceAddress>
    </MatchRule>
  </IPRules>
</AccessControl>