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

Apigee Edge का दस्तावेज़ देखा जा रहा है.
Apigee X के दस्तावेज़ पर जाएं. info

पर क्लिक करें.

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>