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 में बताए गए आईपी पते (ऊपर दिए गए चरण 1) से मेल खाते हों.

    उदाहरण के लिए, इस नीति में <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 में दिए गए खास आईपी पते(पतों) से मिलने वाले एपीआई अनुरोधों का ऐक्सेस रोकना है, तो गड़बड़ी का मैसेज दिख सकता है. इस मामले में आपको कुछ और करने की ज़रूरत नहीं है.

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

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

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