AccessControl-Richtlinie

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation.
Weitere Informationen

Was

Mit der Zugriffssteuerungsrichtlinie können Sie den Zugriff auf Ihre APIs über bestimmte IP-Adressen zulassen oder ablehnen.

Video: In einem kurzen Video erfahren Sie, wie Sie den Zugriff auf Ihre APIs über bestimmte IP-Adressen zulassen oder ablehnen.

Sie können diese Richtlinie an einer beliebigen Stelle im API-Proxy-Ablauf anhängen. Es empfiehlt sich aber, die IP-Adressen zu Beginn des Ablaufs ( Anfrage / ProxyEndpoint / PreFlow) zu prüfen, bevor Sie eine Authentifizierung oder Kontingentprüfung durchführen.

Beispiele

Die Maskenwerte in den folgenden IPv4-Beispielen bestimmen, welches der vier Oktett (8, 16, 24, 32 Bit) die Abgleichsregel berücksichtigt, wenn der Zugriff zugelassen oder verweigert wird. Der Standardwert ist 32. Weitere Informationen finden Sie in der Elementreferenz zum Attribut mask.

198.51.100.1 ablehnen

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

Alle Anfragen von Clientadresse ablehnen: 198.51.100.1

Anfragen von anderer Clientadresse zulassen.

Mithilfe von Variablen ablehnen

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

Angenommen, Sie verwenden eine Schlüsselwertzuordnung (KVM), um Werte für die Maskierung und IP-Adressen zu speichern. Dies ist ein praktisches Verfahren, um IP-Adressen zu ändern und während der Laufzeit zu maskieren, ohne den API-Proxy aktualisieren oder neu bereitstellen zu müssen. Auf der SeiteRichtlinie "KeyValueMapOperations" um die Variablen abzurufen, die die Werte fürkvm.mask.value und kvm.ip.value Dabei wird davon ausgegangen, dass Sie die Variablen in Ihrer KVM-Richtlinie benannt haben, die die Werte der Maske und IP-Werte Ihrer KVM enthalten. Wenn die abgerufenen Werte 24 für die Maske und 198.51.100.1 für die IP-Adresse wären, würde die AccessControl-Richtlinie alle Anfragen von 198.51.100 ablehnen.*

Alle anderen Clientadressen wären zulässig.

198.51.100.* ablehnen

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

Alle Anfragen von Clientadresse ablehnen: 198.51.100.*

Anfragen von anderer Clientadresse zulassen.

198.51.*.*

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

Alle Anfragen von Clientadresse ablehnen: 198.51.*.*

Anfragen von anderer Clientadresse zulassen.

198.51.100.* ablehnen, 192.0.2.1 zulassen

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

Alle Anfragen von der Clientadresse ablehnen: 198.51.100.*, jedoch 192.0.2.1 erlauben.

Anfragen von anderer Clientadresse zulassen.

198.51.*.* zulassen

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

Alle Anfragen von Adresse zulassen: 198.51.*.*

Anfragen von anderer Clientadresse ablehnen.

Mehrere IP-Adressen zulassen

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

Anfragen von Clientadressen zulassen: 198.51.100.* 192.0.2.* 203.0.113.*

Alle anderen Adressen ablehnen.

Mehrere IP-Adressen ablehnen

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

Anfragen von Clientadressen zulassen: 198.51.100.* 192.0.2.* 203.0.113.*

Alle anderen Adressen zulassen.

Mehrere IP-Adressen zulassen, mehrere IP-Adressen ablehnen

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

Zulassen: 198.51.*.* 192.0.*.* 203.0.*.*

Lehnen Sie einen Teil der Zulassen-Liste ab: 198.51.100.* 192.0.2.* 203.0.113.*


Verwendungshinweise

Mit der Zugriffssteuerung können Sie Ihre APIs nicht nur vor schädlichen IP-Adressen schützen, sondern auch den legitimen IP-Zugriff. Wenn Sie beispielsweise nur Computer unter der Kontrolle Ihres Unternehmens auf die APIs in Ihrer Testumgebung zugreifen möchten, können Sie den IP-Adressbereich für Ihr internes Netzwerk zulassen. Entwickler, die von zu Hause aus arbeiten, können über VPN auf diese APIs zugreifen.

Die Konfiguration und Ausführung einer Zugriffssteuerungsrichtlinie umfasst Folgendes:

  • Definieren Sie eine Gruppe von Übereinstimmungsregeln mit einer der beiden Aktionen (ALLOW oder DENY).
  • Geben Sie für jede Übereinstimmungsregel die IP-Adresse an (SourceAddress-Element).
  • Geben Sie die Reihenfolge an, in der die Regeln getestet werden.
  • Alle Übereinstimmungsregeln werden in der angegebenen Reihenfolge ausgeführt. Wenn eine Regel übereinstimmt, wird die entsprechende Aktion ausgeführt und die folgenden Abgleichsregeln werden übersprungen.
    • Wenn dieselbe Regel sowohl mit ALLOW- als auch mit DENY-Aktionen konfiguriert ist, wird die Regel, die zuerst in der Reihenfolge definiert ist, ausgelöst und die nachfolgende Regel (mit der anderen Aktion) wird übersprungen.

So wählt die Richtlinie die zu bewertende IP-Adresse aus

IP-Adressen können aus verschiedenen Quellen in einer Anfrage stammen. Der Nachrichtenheader True-Client-IP könnte beispielsweise eine IP-Adresse enthalten und der Header X-Forwarded-For kann eine oder mehrere IP-Adressen enthalten. In diesem Abschnitt wird beschrieben, wie Sie die AccessControl-Richtlinie konfigurieren, um die genauen IP-Adressen zu bewerten, die bewertet werden sollen.

Im Folgenden ist die Logik aufgeführt, mit der die AccessControl-Richtlinie entscheidet, welche IP-Adresse evaluiert werden soll:

1. True-Client-IP-Header

Die Richtlinie prüft den Header True-Client-IP zuerst auf eine IP-Adresse. Wenn der Header eine gültige IP-Adresse enthält, wird diese Adresse von der Richtlinie evaluiert.

2. X-Forwarded-For-Header

Wenn kein True-Client-IP-Header vorhanden ist oder Sie das <IgnoreTrueClientIPHeader>-Element auf "true" gesetzt haben, wertet die Richtlinie die IP-Adressen im X-Forwarded-For-Header aus.

Edge füllt den X-Forwarded-For-Header automatisch aus durch die IP-Adresse, die er vom letzten externen TCP-Handshake erhalten hat (z. B. die Client-IP oder Router). Wenn der Header mehrere IP-Adressen enthält, handelt es sich höchstwahrscheinlich um die Kette von Servern, die eine Anfrage verarbeitet haben. Die Liste der Adressen kann jedoch auch eine gefälschte IP-Adresse enthalten. Woher weiß die Richtlinie, welche Adressen bewertet werden?

Die Konfiguration der Organisation und die Richtlinienkonfiguration bestimmen, welche X-Forwarded-For-Adresse(n) von der Richtlinie evaluiert werden.

Prüfen Sie zuerst, ob das Attribut feature.enableMultipleXForwardCheckForACL für Ihre Organisation festgelegt ist. Sie können die <ph type="x-smartling-placeholder"></ph> Rufen Sie die Organization API zur Prüfung ab. Dann:

  • Wenn feature.enableMultipleXForwardCheckForACL in der Liste der Attribute Ihrer Organisation nicht angezeigt wird, ist dieses Attribut auf false (Standardeinstellung) gesetzt. Wenn diese Eigenschaft auf „false“ gesetzt ist, wertet die Richtlinie die last-Adresse im Header (sichtbar im Trace-Tool), also die IP-Adresse Edge, der vom letzten externen TCP-Handshake empfangen wurde.
  • Wenn feature.enableMultipleXForwardCheckForACL in Ihrer Organisation auf „true“ gesetzt ist, konfigurieren Sie das Element <ValidateBasedOn>, um zu bestimmen, welche IP-Adressen von der Richtlinie evaluiert werden.

feature.enableMultipleXForwardCheckForACL-Attribut ändern

Edge-Organisationsadministratoren können die <ph type="x-smartling-placeholder"></ph> Aktualisieren Sie die API für Organisationseigenschaften, um die feature.enableMultipleXForwardCheckForACL-Property.

Im folgenden API-Beispiel wird die Eigenschaft in Edge für Private Cloud festgelegt. Wenn für Ihre Organisation noch weitere Eigenschaften festgelegt sind, müssen Sie auch diese angeben. Andernfalls werden sie entfernt.

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

In Edge für Private Cloud, nachdem der Wert der Funktion feature.enableMultipleXForwardCheckForACL Property, müssen Sie Ihre Nachrichtenverarbeiter neu starten, wie unter <ph type="x-smartling-placeholder"></ph> Einzelne Komponenten starten/anhalten/neu starten.

X-Forwarded-For-Dimensionen in Apigee Analytics

Edge Analytics schreibt den Wert des X-Forwarded-For-Headers in den x_forwarded_for_ip Dimension aus. Um die Client-IP-Adresse zu ermitteln, die Anfrage an Edge, verwenden Sie die Werte in ax_true_client_ip oder ax_resolved_client_ip Dimensionen. Weitere Informationen finden Sie unter Analytics-Metriken, -Dimensionen, und Filter.

IP-Masken mit CIDR-Notation

Mithilfe der CIDR-Notation (Classless Inter-Domain Routing) können Sie einen Bereich von IP-Adressen durch Maskierung angeben. Dies gilt sowohl für IPv4 als auch für IPv6. Und so gehts. Zur Vereinfachung verwenden wir in unseren Beispielen IPv4.

IP-Adressen sind durch Punkte getrennte Zahlengruppen. In binärer Form ist jede Gruppe eine bestimmte Anzahl von Bits (8 für IPv4 und 16 für IPv6). Die IPv4-Adresse 198.51.100.1 sieht in binärer Form so aus:

11000110.00110011.01100100.00000001

Das sind 4 Gruppen mit 8 Bit bzw. insgesamt 32 Bits. Mit CIDR können Sie einen Bereich angeben, indem Sie der IP-Adresse eine /Nummer (1-32) hinzufügen:

198.51.100.1/24

In diesem Fall ist 24 die Zahl, die Sie für den Attributwert mask in dieser Richtlinie verwenden würden.

Diese Notation bedeutet: "Lassen Sie die ersten 24 Bits genau so, wie sie sind, die restlichen Bits können einen beliebigen Wert von 0 bis 255 haben." Beispiel:

Belassen Sie sie, wie sie sind Mögliche Werte für die letzte Gruppe
198.51.100. 0–255

Beachten Sie, dass die Maske am Ende von Gruppe 3 erfolgt. Damit wird eine Maske wie diese erstellt: 198.51.100.*. In den meisten Fällen erzielen Sie mit Vielfachen von 8 (IPv4) und 16 (IPv6) die gewünschte Maskenebene:

IPv4: 8, 16, 24, 32

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

Sie können aber auch andere Zahlen für die genauere Steuerung verwenden. Dies erfordert eine kleine Binärberechnung. Im Folgenden sehen Sie ein Beispiel mit einer Maske von 30, wie in 198.51.100.1/30, wobei die letzte 1 das Element 00000001 in binärer Form ist:

Belassen Sie sie, wie sie sind Mögliche Werte
11000110.00110011.01100100.000000 (erste 30 Bit) 00000000, 00000001, 00000010, oder 00000011
198.51.100. 0, 1, 2, oder 3

Wenn in diesem Beispiel die Konfiguration auf <SourceAddress mask="30">198.51.100.1</SourceAddress> gesetzt ist, werden je nach Regeln die folgenden IP-Adressen zugelassen oder abgelehnt:

  • 198.51.100.0
  • 198.51.100.1
  • 198.51.100.2
  • 198.51.100.3

Elementverweis

In der Elementreferenz werden die Elemente und Attribute der Zugriffssteuerungsrichtlinie beschrieben.

<?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>-Attribute

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

In der folgenden Tabelle werden Attribute beschrieben, die für alle übergeordneten Richtlinienelemente gelten:

Attribut Beschreibung Standard Präsenz
name

Der interne Name der Richtlinie. Der Wert des Attributs name kann Buchstaben, Ziffern, Leerzeichen, Bindestriche, Unterstriche und Punkte enthalten. Dieser Wert darf 255 Zeichen nicht überschreiten.

Optional können Sie das Element <DisplayName> verwenden, um die Richtlinie im Proxy-Editor der Verwaltungs-UI mit einem anderen Namen in einer natürlichen Sprache zu versehen.

Erforderlich
continueOnError

Legen Sie false fest, um einen Fehler zurückzugeben, wenn eine Richtlinie fehlschlägt. Dies ist für die meisten Richtlinien das erwartete Verhalten.

Legen Sie true fest, damit die Ablaufausführung auch nach dem Fehlschlagen einer Richtlinie fortgesetzt wird.

false Optional
enabled

Setzen Sie den Wert auf true, um die Richtlinie zu erzwingen.

Legen Sie false fest, um die Richtlinie zu deaktivieren. Die Richtlinie wird nicht erzwungen, selbst wenn sie mit einem Ablauf verknüpft ist.

true Optional
async

Dieses Attribut wurde verworfen.

false Veraltet

<DisplayName>-Element

Wird zusätzlich zum Attribut name verwendet, um die Richtlinie im Proxy-Editor der Verwaltungs-UI mit einem anderen Namen in einer natürlichen Sprache zu versehen.

<DisplayName>Policy Display Name</DisplayName>
Standardeinstellung

Wenn Sie dieses Element weglassen, wird der Wert des Namensattributs name der Richtlinie verwendet.

Präsenz Optional
Typ String

<IgnoreTrueClientIPHeader>-Element

Wenn Sie dies auf "true" setzen, ignoriert die Richtlinie den Header True-Client-IP und wertet IP-Adressen im Header X-Forwarded-For gemäß dem X-Forwarded-For-Evaluierungsverhalten aus, das Sie konfiguriert haben.


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

Standard false
Präsenz Optional
Typ Boolesch

<IPRules>-Element

Das übergeordnete Element mit den Regeln, die IP-Adressen zulassen oder ablehnen. Mit dem Attribut noRuleMatchAction können Sie festlegen, wie IP-Adressen behandelt werden sollen, die nicht von Ihren Abgleichsregeln abgedeckt werden.

<IPRules noRuleMatchAction = "ALLOW">
Standard
Präsenz Optional
Typ

Attribute

Attribut Beschreibung Typ Standard Präsenz
noRuleMatchAction
Die erforderliche Aktion (Zugriff erlauben oder ablehnen), wenn die angegebene Regel nicht aufgelöst wird (keine Übereinstimmung).
Gültiger Wert: ALLOW oder DENY
String ZULASSEN Erforderlich

<IPRules>/<MatchRule>-Element

Die auszuführende Aktion (zulassen oder ablehnen), wenn die IP-Adresse mit den von Ihnen definierten Quelladresse(n) übereinstimmt

<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>
Standard
Präsenz Optional
Typ

Attribute

Attribut Beschreibung Typ Standard Präsenz
Aktion

Die erforderliche Aktion (Zugriff erlauben oder ablehnen), wenn die angegebene Regel nicht aufgelöst wird (keine Übereinstimmung).

Gültiger Wert: ALLOW oder DENY

String ZULASSEN Erforderlich

<IPRules>/<MatchRule>/<SourceAddress>-Element

Der IP-Adressbereich eines Clients.

Gültiger Wert: Gültige IP-Adresse (Dezimalformat mit Punkten) Für Platzhalterverhalten verwenden Sie das Attribut 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>

Wie im vorherigen Beispiel gezeigt, unterstützt das Element SourceAddress auch Nachrichtenvorlagen für das Attribut mask oder die IP-Adresse. Das bedeutet, dass Sie die Werte mit Hilfe von Variablen einstellen können, die derzeit im API-Proxy-Ablauf verfügbar sind.

Sie können beispielsweise eine IP-Adresse in einer Schlüssel/Wert-Paarzuordnung (KVM) speichern und die KeyValueMapOperations-Richtlinie verwenden, um die IP-Adresse abzurufen und einer Variablen zuzuweisen (z. B. kvm.ip.value). Sie können diese Variable dann für die IP-Adresse verwenden:

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

Wenn Sie eine Maske und/oder IP-Adresse mit einer Variablen festlegen, können Sie Werte zur Laufzeit ändern, ohne den API-Proxy ändern oder neu bereitstellen zu müssen.

Standard
Präsenz Optional
Typ String (nur eine einzelne IP-Adresse)

Attribute

Attribut Beschreibung Typ Standard Präsenz
Maske

Mit dem Attribut mask geben Sie den zulässigen IP-Adressbereich an. Maske ist das Äquivalent zur Verwendung von CIDR-Notation (Classless Inter-Domain Routing). Beispiel:

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

entspricht der folgenden CIDR-Notation:

198.51.100.1/24

Zulässige Werte:

IPv4: 1–32

IPv6: 1–128

Ein Wert von null (0) ist nur für die IP-Adresse 0.0.0.0 gültig, und daher unpraktisch.

Maske mit einer Variablen festlegen

Das Attribut mask unterstützt auch Nachrichtenvorlagen. Das bedeutet, dass Sie den Wert mit einer Variablen festlegen können, die derzeit im API-Proxy-Flow verfügbar ist. Sie können beispielsweise einen Maskenwert in einer KVM speichern und die KeyValueMapOperations-Richtlinie verwenden, um die Maske abzurufen und einer Variablen zuzuweisen. Um die IP-Maske mit der Variablen festzulegen, verwenden Sie das folgende Format unter der Annahme, dass die Variable den Namen kvm.mask.value hat:

mask="{kvm.mask.value}"

Ganzzahl Erforderlich

<ValidateBasedOn>-Element

Wenn der HTTP-Header X-Forwarded-For mehrere IP-Adressen enthält, können Sie mit diesem ValidateBasedOn-Element steuern, welche IP-Adressen evaluiert werden.

Verwenden Sie diesen Ansatz zur Auswertung von IP-Adressen nur, wenn Sie sich über die Gültigkeit der IP-Adressen, die Sie auswerten möchten, sicher sind. Wenn Sie sich beispielsweise dafür entscheiden, alle IP-Adressen im Header X-Forwarded-For auszuwerten, müssen Sie in der Lage sein, der Gültigkeit dieser Adressen zu vertrauen und/oder umfassende DENY- oder ALLOW-Regeln aufzustellen, damit nur vertrauenswürdige IPs Ihren API-Proxy aufrufen können.

Die ganz linke IP-Adresse im Header gehört dem Client, und die ganz rechte ist der Server, der die Anfrage an den aktuellen Dienst weitergeleitet hat. Mit der letzten IP-Adresse ganz rechts ist der vom letzten externen TCP-Handshake empfangene Adress-Edge.

Mit dem Wert, den Sie in dieses Element eingeben, können Sie festlegen, ob alle IP-Adressen im Header (Standard), nur die erste IP-Adresse oder nur die letzte IP-Adresse geprüft werden soll.

<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>
Standard X_FORWARDED_FOR_ALL_IP
Präsenz Optional
Zulässige Werte

X_FORWARDED_FOR_ALL_IP (Standard)

X_FORWARDED_FOR_FIRST_IP

X_FORWARDED_FOR_LAST_IP

Schemas

Jeder Richtlinientyp wird durch ein XML-Schema (.xsd) definiert. Zu Referenzzwecken sind Richtlinienschemas auf GitHub verfügbar.

Fehlerreferenz

Dieser Abschnitt beschreibt die Fehlercodes und Fehlermeldungen, die zurückgegeben werden, und die Fehlervariablen, die von Edge festgelegt werden, wenn diese Richtlinie einen Fehler auslöst. Diese Informationen sind wichtig, wenn Sie Fehlerregeln zur Verarbeitung von Fehlern entwickeln. Weitere Informationen finden Sie unter Was Sie über Richtlinienfehler wissen müssen und Fehler beheben.

Laufzeitfehler

Diese Fehler können bei Ausführung der Richtlinie auftreten.

Fehlercode HTTP-Status Ursache Beheben
accesscontrol.IPDeniedAccess 403 Die Client-IP-Adresse oder eine in der API-Anfrage übergebene IP-Adresse entspricht einer IP-Adresse, die im Element <SourceAddress> des Elements <MatchRule> der Zugriffssteuerungsrichtlinie angegeben ist, und das Attribut action des Elements <MatchRule> ist auf DENY festgelegt.

Fehlervariablen

Diese Variablen werden bei Laufzeitfehlern festgelegt. Weitere Informationen finden Sie unter Für Richtlinienfehler spezifische Variablen.

Variablen Wo Beispiel
fault.name="fault_name" fault_name ist der Name des Fehlers, der in der obigen Tabelle Laufzeitfehler aufgeführt ist. Der Fehlername ist der letzte Teil des Fehlercodes. fault.name Matches "IPDeniedAccess"
acl.policy_name.failed policy_name ist der benutzerdefinierte Name der Richtlinie, die den Fehler ausgelöst hat. acl.AC-AllowAccess.failed = true

Beispiel für eine Fehlerantwort

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

Beispiel für eine Fehlerregel

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