AccessControl नीति

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

यह क्या है

ऐक्सेस कंट्रोल नीति की मदद से, कुछ खास आईपी पतों से अपने एपीआई को ऐक्सेस करने की अनुमति दी जा सकती है या उन्हें अस्वीकार किया जा सकता है.

वीडियो: खास आईपी पतों से अपने एपीआई का ऐक्सेस देने या न देने के बारे में ज़्यादा जानने के लिए, यह छोटा वीडियो देखें.

इस नीति को एपीआई प्रॉक्सी फ़्लो में कहीं भी अटैच किया जा सकता है. हालांकि, ऐसा हो सकता है कि आप फ़्लो की शुरुआत में ही आईपी पतों की जांच करना चाहें ( Request / प्रॉक्सीEndpoint / PreFlow), पुष्टि करने या कोटा की जांच करने से पहले भी ऐसा किया जा सकता है.

सैंपल

नीचे दिए गए IPv4 सैंपल में मास्क की वैल्यू पहचान करती हैं कि ऐक्सेस की अनुमति देते या न देते समय, मैच का नियम चार ऑक्टेट (8, 16, 24, 32 बिट) में से किस पर विचार करता है. डिफ़ॉल्ट वैल्यू 32 है. ज़्यादा जानकारी के लिए, एलिमेंट रेफ़रंस में mask एट्रिब्यूट देखें.

198.51.100.1 का अनुरोध अस्वीकार करें

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

क्लाइंट के ईमेल पते से मिले सभी अनुरोधों को अस्वीकार करें: 198.51.100.1

किसी अन्य क्लाइंट पते से मिलने वाले अनुरोधों को अनुमति दें.

वैरिएबल का इस्तेमाल करने से मना करें

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "ALLOW">
    <MatchRule action = "DENY">
      <SourceAddress mask="{kvm.mask.value}">{kvm.ip.value}</SourceAddress>
    </MatchRule>
    </IPRules>
</AccessControl>

मान लें कि मास्किंग और आईपी की वैल्यू सेव करने के लिए, की-वैल्यू मैप (केवीएम) का इस्तेमाल किया जा रहा है. यह रनटाइम के दौरान, आईपी प्रॉक्सी को अपडेट करने और उसे फिर से इस्तेमाल किए बिना मास्क करने का एक आसान तरीका है. KeyValueMapOperations नीति का इस्तेमाल करके, kvm.mask.value और kvm.ip.value की वैल्यू वाले वैरिएबल वापस पाए जा सकते हैं. यह मानते हुए कि आपने अपनी केवीएम नीति में वैरिएबल का नाम दिया है, जिनमें आपके केवीएम के मास्क और आईपी वैल्यू वाली वैल्यू शामिल हैं. अगर वापस मिली वैल्यू, मास्क के लिए 24 और आईपी पते के लिए 198.51.100.1 थीं, तो AccessControl के तहत 198.51.100 से मिलने वाले सभी अनुरोधों को अस्वीकार कर दिया जाएगा.*

दूसरे सभी क्लाइंट के पतों की अनुमति होगी.

198.51.100* को अस्वीकार करें.

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

क्लाइंट के ईमेल पते से मिले सभी अनुरोध अस्वीकार करें: 198.51.100.*

किसी अन्य क्लाइंट पते से मिलने वाले अनुरोधों को अनुमति दें.

198.51.*.*

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

क्लाइंट पते से मिले सभी अनुरोध अस्वीकार करें: 198.51.*.*

किसी अन्य क्लाइंट पते से मिलने वाले अनुरोधों को अनुमति दें.

198.51.100.* को अस्वीकार करें, 192.0.2.1 को अनुमति दें

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

क्लाइंट पते से मिले सभी अनुरोधों को अस्वीकार करें: 198.51.100.*, लेकिन 192.0.2.1 को अनुमति दें.

किसी अन्य क्लाइंट पते से मिलने वाले अनुरोधों को अनुमति दें.

198.51.*.* अनुमति दें

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

इस पते से सभी अनुरोधों की अनुमति दें: 198.51.*.*

किसी दूसरे क्लाइंट पते से मिलने वाले अनुरोध अस्वीकार करें.

एक से ज़्यादा आईपी को अनुमति दें

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "DENY">
    <MatchRule action = "ALLOW">
      <SourceAddress mask="24">198.51.100.1</SourceAddress>
      <SourceAddress mask="24">192.0.2.1</SourceAddress>
      <SourceAddress mask="24">203.0.113.1</SourceAddress>
     </MatchRule>
  </IPRules>
</AccessControl>

क्लाइंट पतों से मिलने वाले अनुरोधों को अनुमति दें: 198.51.100.* 192.0.2.* 203.0.113.*

दूसरे सभी ईमेल पतों की मंज़ूरी न दें.

एक से ज़्यादा आईपी दिखाने की अनुमति न दें

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "ALLOW">
    <MatchRule action = "DENY">
      <SourceAddress mask="24">198.51.100.1</SourceAddress>
      <SourceAddress mask="24">192.0.2.1</SourceAddress>
      <SourceAddress mask="24">203.0.113.1</SourceAddress>
    </MatchRule>
  </IPRules>
</AccessControl>

क्लाइंट पतों से मिले अनुरोधों को अस्वीकार करें: 198.51.100.* 192.0.2.* 203.0.113.*

अन्य सभी पतों को अनुमति दें.

एक से ज़्यादा आईपी को अनुमति दें, लेकिन एक से ज़्यादा आईपी को अस्वीकार करने की अनुमति दें

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "DENY">
    <MatchRule action = "DENY">
      <SourceAddress mask="24">198.51.100.1</SourceAddress>
      <SourceAddress mask="24">192.0.2.1</SourceAddress>
      <SourceAddress mask="24">203.0.113.1</SourceAddress>
    </MatchRule>
    <MatchRule action = "ALLOW">
      <SourceAddress mask="16">198.51.100.1</SourceAddress>
      <SourceAddress mask="16">192.0.2.1</SourceAddress>
      <SourceAddress mask="16">203.0.113.1</SourceAddress>
    </MatchRule>
  </IPRules>
</AccessControl>

अनुमति दें: 198.51.*.* 192.0.*.* 203.0.*.*

अनुमति वाली सूची के सबसेट को अस्वीकार करें: 198.51.100.* 192.0.2.* 203.0.113.*


इस्तेमाल की जानकारी

आपके एपीआई को नुकसान पहुंचाने वाले आईपी से सुरक्षित रखने के साथ-साथ, ऐक्सेस कंट्रोल की नीति से यह भी तय किया जा सकता है कि कानूनी तौर पर सही आईपी पते का इस्तेमाल कैसे किया जाए. उदाहरण के लिए, अगर आपको सिर्फ़ अपने एंटरप्राइज़ के कंट्रोल में मौजूद कंप्यूटर को, टेस्ट एनवायरमेंट में दिखने वाले एपीआई ऐक्सेस करने की अनुमति देनी है, तो अपने इंटरनल नेटवर्क के लिए आईपी पता रेंज को अनुमति दें. घर से काम करने वाले डेवलपर, वीपीएन का इस्तेमाल करके इन एपीआई को ऐक्सेस कर सकते हैं.

ऐक्सेस कंट्रोल की नीति को कॉन्फ़िगर करने और उसे लागू करने में ये चीज़ें शामिल होती हैं:

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

नीति यह कैसे चुनती है कि किस आईपी पते की जांच करनी है

आईपी पते, किसी अनुरोध में अलग-अलग सोर्स से आ सकते हैं. उदाहरण के लिए, True-Client-IP मैसेज के हेडर में आईपी पता हो सकता है और X-Forwarded-For हेडर में एक या उससे ज़्यादा आईपी पते हो सकते हैं. इस सेक्शन में बताया गया है कि AccessControl की नीति को कॉन्फ़िगर कैसे किया जाए, ताकि उन सटीक आईपी पतों का आकलन किया जा सके जिनका आकलन करना है.

AccessControl नीति, इस लॉजिक का इस्तेमाल करके यह तय करती है कि किस आईपी पते की जांच करनी है:

1. True-Client-IP हेडर

नीति सबसे पहले True-Client-IP हेडर में आईपी पते की जांच करती है. अगर हेडर में मान्य आईपी पता है, तो नीति उस पते की जांच करती है.

2. हेडर के लिए X-फ़ॉरवर्ड किया गया

अगर कोई True-Client-IP हेडर नहीं है या आपने <IgnoreTrueClientIPHeader> एलिमेंट को सही पर सेट किया है, तो यह नीति X-Forwarded-For हेडर में आईपी पतों की जांच करती है.

Edge, X-Forwarded-For हेडर को उस आईपी पते से अपने-आप भर देता है जो पिछले एक्सटर्नल टीसीपी हैंडशेक (जैसे कि क्लाइंट आईपी या राऊटर) से मिला था. अगर हेडर में एक से ज़्यादा आईपी पते हैं, तो हो सकता है कि वे पते, अनुरोध को प्रोसेस करने वाले सर्वर की चेन हों. हालांकि, पतों की सूची में स्पूफ़ किया गया आईपी पता भी शामिल हो सकता है. इसलिए, नीति को कैसे पता चलता है कि किन पतों का आकलन करना है?

आपके संगठन के कॉन्फ़िगरेशन और नीति के कॉन्फ़िगरेशन से यह तय होता है कि इस नीति से किस X-Forwarded-For पते(पतों) का आकलन किया जाएगा.

सबसे पहले, यह देख लें कि feature.enableMultipleXForwardCheckForACL प्रॉपर्टी आपके संगठन पर सेट है या नहीं. जांच करने के लिए, Get Organization API का इस्तेमाल किया जा सकता है. इसके बाद:

  • अगर आपको अपने संगठन की प्रॉपर्टी की सूची में feature.enableMultipleXForwardCheckForACL नहीं दिखता है, तो इसका मतलब है कि प्रॉपर्टी false (डिफ़ॉल्ट) पर सेट है. इस प्रॉपर्टी को 'गलत है' पर सेट करने पर, नीति हेडर में मौजूद पिछले पते (ट्रेस टूल में दिख रहा है) का आकलन करती है. यह आईपी पता वह होता है जिसे आखिरी एक्सटर्नल टीसीपी हैंडशेक से मिला था.
  • अगर आपके संगठन के feature.enableMultipleXForwardCheckForACL को 'सही है' पर सेट किया गया है, तो <ValidateBasedOn> एलिमेंट को कॉन्फ़िगर करें, ताकि यह तय किया जा सके कि यह नीति किन आईपी पतों का आकलन करती है.

feature.enableMultipleXForwardCheckForACL प्रॉपर्टी को बदला जा रहा है

एज संगठन के एडमिन, feature.enableMultipleXForwardCheckForACL प्रॉपर्टी को सेट करने के लिए संगठन की प्रॉपर्टी अपडेट करें एपीआई का इस्तेमाल कर सकते हैं.

नीचे दिए गए एपीआई के उदाहरण में, प्राइवेट क्लाउड के लिए Edge में प्रॉपर्टी सेट की गई है. अगर आपके संगठन में अन्य प्रॉपर्टी सेट अप की गई हैं, तो उन्हें भी शामिल करें. ऐसा न करने पर, उन्हें हटा दिया जाएगा.

curl -u email:password -X POST -H "Content-type:application/xml" http://host:8080/v1/o/myorg -d \
"<Organization type="trial" name="MyOrganization">
    <DisplayName>MyOrganization</DisplayName>
    <Properties>
        <Property name="feature.enableMultipleXForwardCheckForACL">true</Property>
        <!-- Include other existing properties as well. -->
    </Properties>
</Organization>"

Edge for Private Cloud में, feature.enableMultipleXForwardCheckForACL प्रॉपर्टी की वैल्यू बदलने के बाद, आपको अपने मैसेज प्रोसेसर को रीस्टार्ट करना होगा. इसके लिए, अलग-अलग कॉम्पोनेंट को चालू/बंद करें/फिर से शुरू करें में बताया गया तरीका अपनाएं.

Apigee Analytics में मौजूद डाइमेंशन के लिए, X-फ़ॉरवर्ड करें

Edge Analytics, X-Forwarded-For हेडर की वैल्यू को x_forwarded_for_ip डाइमेंशन में लिखता है. Edge का अनुरोध करने वाले क्लाइंट आईपी का पता लगाने के लिए, ax_true_client_ip या ax_resolved_client_ip डाइमेंशन की वैल्यू का इस्तेमाल करें. ज़्यादा जानकारी के लिए, Analytics मेट्रिक, डाइमेंशन, और फ़िल्टर रेफ़रंस देखें.

सीआईडीआर नोटेशन के साथ आईपी मास्किंग के बारे में जानकारी

सीआईडीआर नोटेशन (क्लासलेस इंटर-डोमेन रूटिंग), मास्किंग की मदद से कई आईपी पतों के बारे में जानकारी देने का एक तरीका है. यह IPv4 और IPv6, दोनों पर लागू होता है. अब जानते हैं कि यह टूल कैसे काम करता है. आसानी के लिए, हम अपने उदाहरणों में आईपीवी4 का इस्तेमाल करेंगे.

आईपी पते, संख्याओं के ऐसे ग्रुप होते हैं जिन्हें पूर्ण विराम लगाकर अलग किया जाता है. बाइनरी शब्दों में, हर ग्रुप बिट की खास संख्या होती है (IPv4 के लिए 8 और IPv6 के लिए 16). IPv4 पता 198.51.100.1 बाइनरी में ऐसा दिखता है:

11000110.00110011.01100100.00000001

यह 8 बिट के चार ग्रुप या कुल 32 बिट है. सीआईडीआर की मदद से, आईपी पते में /number (1-32) जोड़कर किसी रेंज को दिखाया जा सकता है, जैसे कि:

198.51.100.1/24

इस मामले में, 24 वह संख्या है जिसका इस्तेमाल आपको इस नीति में mask एट्रिब्यूट की वैल्यू के लिए करना है.

इस नोटेशन का मतलब है, "पहले 24 बिट को बिलकुल वैसा ही रखें. बाकी के बिट, 0 से लेकर 255 तक की कोई भी वैल्यू हो सकती है." उदाहरण के लिए:

इन्हें ऐसे ही रखें आखिरी ग्रुप के लिए संभावित वैल्यू
198.51.100. 0 से 255

ध्यान दें कि मास्क तीन ग्रुप के आखिर में होता है. इससे चीज़ें अच्छी और व्यवस्थित हो जाती हैं, ताकि इस तरह का मास्क बनाया जा सके: 198.51.100.*. ज़्यादातर मामलों में, 8 (IPv4) और 16 (IPv6) के मल्टीपल का इस्तेमाल करने से, आपको मास्किंग का वह लेवल मिल जाएगा जो आपको चाहिए:

IPv4: 8, 16, 24, 32

IPv6: 16, 32, 48, 64, 80, 96, 112, 128

हालांकि, ज़्यादा बारीकी से कंट्रोल करने के लिए, दूसरी संख्याओं का इस्तेमाल किया जा सकता है. इसमें बाइनरी कैलकुलेशन की थोड़ी सी प्रोसेस शामिल होती है. यहां 198.51.100.1/30 जैसा 30 मास्क इस्तेमाल करने वाला एक उदाहरण दिया गया है, जहां आखिरी 1, बाइनरी में 00000001 है:

इन्हें ऐसे ही रखें संभावित वैल्यू
11000110.00110011.01100100.000000 (पहले 30 बिट) 00000000, 00000001, 00000010 या 00000011
198.51.100. 0, 1, 2 या 3

इस उदाहरण में, कॉन्फ़िगरेशन को <SourceAddress mask="30">198.51.100.1</SourceAddress> पर सेट करने के बाद, इन आईपी को अनुमति दी जाएगी (या आपके नियमों के आधार पर, इन्हें अस्वीकार कर दिया जाएगा):

  • 198.51.100.0
  • 198.51.100.1
  • 198.51.100.2
  • 198.51.100.3

एलिमेंट का रेफ़रंस

एलिमेंट रेफ़रंस, ऐक्सेस कंट्रोल नीति के एलिमेंट और एट्रिब्यूट के बारे में बताता है.

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

<AccessControl> एट्रिब्यूट

<AccessControl async="false" continueOnError="false" enabled="true" name="Access-Control-1"> 

इस टेबल में उन एट्रिब्यूट के बारे में बताया गया है जो नीति के सभी पैरंट एलिमेंट के लिए एक जैसे होते हैं:

एट्रिब्यूट ब्यौरा डिफ़ॉल्ट मौजूदगी
name

नीति का अंदरूनी नाम. name एट्रिब्यूट की वैल्यू में अक्षर, संख्याएं, स्पेस, हाइफ़न, अंडरस्कोर, और पीरियड शामिल किए जा सकते हैं. इस वैल्यू में 255 से ज़्यादा वर्ण नहीं हो सकते.

इसके अलावा, मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) प्रॉक्सी एडिटर में नीति को आम भाषा में अलग नाम से लेबल करने के लिए, <DisplayName> एलिमेंट का इस्तेमाल करें.

लागू नहीं ज़रूरी है
continueOnError

इस नीति को false पर सेट करें, ताकि नीति के काम न करने पर गड़बड़ी का मैसेज दिखे. ज़्यादातर नीतियों में, ऐसा आम तौर पर किया जाता है.

किसी नीति के काम न करने पर भी फ़्लो एक्ज़ीक्यूट करने की प्रोसेस को जारी रखने के लिए, true पर सेट करें.

false ज़रूरी नहीं
enabled

नीति लागू करने के लिए, true पर सेट करें.

नीति को बंद करने के लिए, false पर सेट करें. अगर यह नीति किसी फ़्लो से जुड़ी हुई है, तब भी उसे लागू नहीं किया जाएगा.

सही ज़रूरी नहीं
async

यह एट्रिब्यूट अब काम नहीं करता.

false बहिष्कृत

<DisplayName> एलिमेंट

मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) प्रॉक्सी एडिटर में, आम भाषा के अलग नाम से नीति को लेबल करने के लिए, name एट्रिब्यूट का इस्तेमाल करें.

<DisplayName>Policy Display Name</DisplayName>
डिफ़ॉल्ट

लागू नहीं

अगर इस एलिमेंट को छोड़ दिया जाता है, तो नीति के name एट्रिब्यूट की वैल्यू का इस्तेमाल किया जाता है.

मौजूदगी ज़रूरी नहीं
Type String

<ignoreTrueClientIPHeader> एलिमेंट

इसे 'सही है' पर सेट करने पर, नीति True-Client-IP हेडर को अनदेखा करती है और X-Forwarded-For हेडर के आईपी पतों का आकलन करती है. ऐसा कॉन्फ़िगर किए गए X-Forwarded-मूल्यांकन के व्यवहार के आधार पर की जाती है.


<AccessControl async="false" continueOnError="false" enabled="true" name="Access-Control-1">
    <DisplayName>Access Control-1</DisplayName>
    <IgnoreTrueClientIPHeader>true</IgnoreTrueClientIPHeader>
    ...
</AccessControl>

डिफ़ॉल्ट false
मौजूदगी ज़रूरी नहीं
Type बूलियन

<IPTerms> एलिमेंट

वह पैरंट एलिमेंट जिसमें आईपी पतों को अनुमति देने या अस्वीकार करने वाले नियम होते हैं. noRuleMatchAction एट्रिब्यूट की मदद से, यह तय किया जा सकता है कि उन आईपी पतों को कैसे मैनेज किया जाए जो आपके मैच करने वाले नियमों के दायरे में नहीं आते.

<IPRules noRuleMatchAction = "ALLOW">
डिफ़ॉल्ट लागू नहीं
मौजूदगी ज़रूरी नहीं
Type लागू नहीं

एट्रिब्यूट

एट्रिब्यूट ब्यौरा Type डिफ़ॉल्ट मौजूदगी
noRuleMatchAction
अगर बताए गए मिलते-जुलते नियम की समस्या हल नहीं होती है (मेल न खाने वाला) तो कार्रवाई (ऐक्सेस की अनुमति देना या अस्वीकार करना).
मान्य मान: अनुमति दें या अनुमति नहीं दें
String अनुमति दें ज़रूरी है

<IPTerms>/<MatchTerms> एलिमेंट

अगर आईपी पता आपके तय किए गए SourceAddress से मेल खाता है, तो कार्रवाई (ऐक्सेस की अनुमति देना या अस्वीकार करना).

<IPRules noRuleMatchAction = "ALLOW">
    <MatchRule action = "ALLOW">
        <SourceAddress mask="32">198.51.100.1</SourceAddress>
    </MatchRule>
    <MatchRule action = "DENY">
        <SourceAddress mask="24">198.51.100.1</SourceAddress>
    </MatchRule>
</IPRules>
डिफ़ॉल्ट लागू नहीं
मौजूदगी ज़रूरी नहीं
Type लागू नहीं

एट्रिब्यूट

एट्रिब्यूट ब्यौरा Type डिफ़ॉल्ट मौजूदगी
किसी खास रूटीन से जुड़ी कार्रवाई

अगर बताए गए मिलते-जुलते नियम की समस्या हल नहीं होती है (मेल न खाने वाला) तो कार्रवाई (ऐक्सेस की अनुमति देना या अस्वीकार करना).

मान्य मान: अनुमति दें या अनुमति नहीं दें

String अनुमति दें ज़रूरी है

<IPनियमों>/<MatchTerms>/<SourceAddress> एलिमेंट

क्लाइंट के आईपी पते की रेंज.

मान्य वैल्यू: मान्य आईपी पता (डॉट वाला दशमलव नोटेशन). वाइल्डकार्ड के व्यवहार के लिए, mask एट्रिब्यूट का इस्तेमाल करें.

<IPRules noRuleMatchAction = "ALLOW">
    <MatchRule action = "ALLOW">
        <SourceAddress mask="{variable}">198.51.100.1</SourceAddress>
    </MatchRule>
    <MatchRule action = "DENY">
        <SourceAddress mask="24">{variable}</SourceAddress>
    </MatchRule>
</IPRules>

जैसा कि पिछले उदाहरण में दिखाया गया है, SourceAddress एलिमेंट mask एट्रिब्यूट या आईपी पते के लिए, मैसेज टेंप्लेट के साथ भी काम करता है. इसका मतलब है कि एपीआई प्रॉक्सी फ़्लो में उपलब्ध वैरिएबल का इस्तेमाल करके वैल्यू सेट की जा सकती हैं.

उदाहरण के लिए, किसी आईपी पते को की-वैल्यू मैप (केवीएम) में स्टोर किया जा सकता है और KeyValueMapOperations नीति का इस्तेमाल करके, आईपी पते को हासिल किया जा सकता है और उसे kvm.ip.value जैसे वैरिएबल को असाइन किया जा सकता है. इसके बाद, उस वैरिएबल का इस्तेमाल, आईपी पते के लिए किया जा सकता है:

<SourceAddress mask="24">{kvm.ip.value}</SourceAddress>

मास्क और/या आईपी पते को वैरिएबल के साथ सेट करने से, आपको एपीआई प्रॉक्सी में बदलाव किए बिना और उसे फिर से डिप्लॉय किए बिना, रनटाइम के दौरान वैल्यू बदलने की सुविधा मिलती है.

डिफ़ॉल्ट लागू नहीं
मौजूदगी ज़रूरी नहीं
Type स्ट्रिंग (सिर्फ़ एक आईपी पता)

एट्रिब्यूट

एट्रिब्यूट ब्यौरा Type डिफ़ॉल्ट मौजूदगी
मास्क

mask एट्रिब्यूट से, ऐसे आईपी पतों की रेंज के बारे में पता चलता है जिन्हें अनुमति देनी है या अस्वीकार करना है. मास्क, सीआईडीआर नोटेशन (क्लासलेस इंटर-डोमेन रूटिंग) इस्तेमाल करने जैसा ही है. उदाहरण के लिए:

<SourceAddress mask="24">198.51.100.1</SourceAddress>

नीचे दिए गए सीआईडीआर नोटेशन के बराबर है:

198.51.100.1/24

मान्य मान:

IPv4: 1-32

आईपीवी6: 1-128

शून्य (0) की वैल्यू सिर्फ़ आईपी 0.0.0.0 के लिए मान्य है, इसलिए यह मान्य नहीं है.

मास्क को वैरिएबल के साथ सेट करना

mask एट्रिब्यूट, मैसेज टेंप्लेट के साथ भी काम करता है. इसका मतलब है कि आपके पास वैल्यू को ऐसे वैरिएबल के साथ सेट करने का विकल्प है जो फ़िलहाल एपीआई प्रॉक्सी फ़्लो में उपलब्ध है. उदाहरण के लिए, मास्क की वैल्यू को केवीएम में स्टोर किया जा सकता है. साथ ही, मास्क को फिर से पाने और उसे किसी वैरिएबल को असाइन करने के लिए, KeyValueMapOperations नीति का इस्तेमाल करें. वैरिएबल के साथ आईपी मास्क सेट करने के लिए, यह मानते हुए कि वैरिएबल का नाम kvm.mask.value है, यह फ़ॉर्मैट इस्तेमाल करें:

mask="{kvm.mask.value}"

Integer लागू नहीं ज़रूरी है

<ValidatebasedOn> एलिमेंट

जब X-Forwarded-For एचटीटीपी हेडर में एक से ज़्यादा आईपी पते शामिल हों, तो इस ValidateBasedOn एलिमेंट का इस्तेमाल करके यह कंट्रोल किया जा सकता है कि किन आईपी पतों का आकलन किया जाए.

इस तरीके का इस्तेमाल करके किसी आईपी पतों का आकलन सिर्फ़ तब करें, जब आपको पता हो कि आपको उन आईपी पतों की पुष्टि करनी है जिनकी आपको जांच करनी है. उदाहरण के लिए, अगर X-Forwarded-For हेडर में सभी आईपी पतों का आकलन करना है, तो आपको उन पतों की मान्यता पर भरोसा करना होगा और/या 'अनुमति नहीं दें' या 'अनुमति दें' नियम सेट अप करने होंगे, ताकि सिर्फ़ भरोसेमंद आईपी आपके एपीआई प्रॉक्सी को कॉल कर सकें.

हेडर में सबसे बाईं ओर का आईपी पता क्लाइंट का होता है और सबसे दाईं ओर वह सर्वर होता है जिसने मौजूदा सेवा को अनुरोध फ़ॉरवर्ड किया था. सबसे दाईं ओर का या आखिरी आईपी पता, वह पता होता है जो आखिरी बार एक्सटर्नल टीसीपी हैंडशेक से मिला था.

इस एलिमेंट में आपकी डाली गई वैल्यू से यह तय किया जा सकता है कि हेडर (डिफ़ॉल्ट) में सभी आईपी पतों की जांच करनी है, सिर्फ़ पहले आईपी पते की जांच करनी है या सिर्फ़ आखिरी आईपी पते में.

<AccessControl async="false" continueOnError="false" enabled="true" name="Access-Control-1">
    <DisplayName>Access Control 1</DisplayName>
    <IPRules noRuleMatchAction = "ALLOW">
        <MatchRule action = "DENY">
            <SourceAddress mask="32">198.51.100.1</SourceAddress>
        </MatchRule>
    </IPRules>
    <ValidateBasedOn>X_FORWARDED_FOR_ALL_IP</ValidateBasedOn>
</AccessControl>
डिफ़ॉल्ट X_FORWARDED_FOR_ALL_IP
मौजूदगी ज़रूरी नहीं
मान्य वैल्यू

X_FORWARDED_FOR_ALL_IP (डिफ़ॉल्ट)

X_FORWARDED_FOR_FIRST_IP

X_FORWARDED_FOR_LAST_IP

स्कीमा

हर तरह की नीति को एक्सएमएल स्कीमा (.xsd) से तय किया जाता है. रेफ़रंस के लिए, नीति के स्कीमा GitHub पर उपलब्ध हैं.

गड़बड़ी का रेफ़रंस

यह सेक्शन गड़बड़ी के कोड और दिखाए गए गड़बड़ी के मैसेज के बारे में बताता है. साथ ही, इस नीति के ट्रिगर होने पर Edge की मदद से सेट की गई गड़बड़ी के वैरिएबल के बारे में बताता है. यह जानकारी जानना ज़रूरी है कि क्या गड़बड़ियों को ठीक करने के लिए, गड़बड़ी से जुड़े नियम बनाए जा रहे हैं. ज़्यादा जानने के लिए, नीति से जुड़ी गड़बड़ियों के बारे में आपके लिए ज़रूरी जानकारी और गड़बड़ियों को ठीक करने के तरीके देखें.

रनटाइम से जुड़ी गड़बड़ियां

नीति के लागू होने पर ये गड़बड़ियां हो सकती हैं.

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

गड़बड़ी वाले वैरिएबल

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

वैरिएबल जगह उदाहरण
fault.name="fault_name" fault_name, गड़बड़ी का नाम है, जैसा कि ऊपर रनटाइम की गड़बड़ियां टेबल में दिया गया है. गड़बड़ी का नाम, गड़बड़ी के कोड का आखिरी हिस्सा होता है. fault.name Matches "IPDeniedAccess"
acl.policy_name.failed policy_name, उस नीति का उपयोगकर्ता तय किया गया नाम है जिसकी वजह से गड़बड़ी हुई है. acl.AC-AllowAccess.failed = true

गड़बड़ी के जवाब का उदाहरण

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

गड़बड़ी के नियम का उदाहरण

<FaultRule name="IPDeniedAccess">
    <Step>
        <Name>AM-IPDeniedAccess</Name>
        <Condition>(fault.name Matches "IPDeniedAccess") </Condition>
    </Step>
    <Condition>(acl.failed = true) </Condition>
</FaultRule>