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-forwarded-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>