Statische IP für APIs: IP-Autorisierungsfehler beheben

Gestern Abend lief die Integration: Die Bestellliste kam, die SMS ging raus. Heute Morgen liefert derselbe Code mit demselben Schlüssel „IP-Autorisierung erforderlich“ oder ein nacktes 403. Am Code hat sich nichts geändert. Geändert hat sich die Adresse, von der Ihre Anfrage ins Internet geht: Der Router hat sich nachts neu verbunden, eine Kollegin im Homeoffice hat es über ihren eigenen Anschluss versucht, oder die Anwendung ist auf einen anderen Server umgezogen. Der Dienst auf der Gegenseite kennt aber nur die Adresse, die ihm vorab gemeldet wurde.

In diesem Beitrag erklären wir, wie die IP-Autorisierung bei APIs funktioniert, in welchen Situationen die Meldung erscheint und wie Sie die Ausgangs-IP ermitteln, die der Dienst tatsächlich sieht. Danach vergleichen wir die vier Wege zu einer festen Ausgangsadresse (statische IP vom Internetanbieter, Server mit fester IP, NAT-Gateway und statischer Proxy) in einer Tabelle. Welcher Weg bei Zahlungs-, Gesundheits- und E-Rechnungs-Integrationen nicht gewählt werden sollte, behandeln wir in einem eigenen Abschnitt. Am Ende steht ein getestetes Python- und Node.js-Beispiel, das Ihre Ausgangsadresse überprüft.

Was ist IP-Autorisierung bei APIs?#

IP-Autorisierung (Liste erlaubter IPs, in den meisten Dokumentationen „IP-Whitelist“ oder „Allowlist“) bedeutet, dass ein Dienst eine eingehende Anfrage nach ihrer Quelladresse filtert, bevor er sich den Inhalt ansieht. Im Dashboard des Dienstes oder in den Unterlagen des Supports liegt eine Adressliste, die zu Ihrem Konto gehört. Kommt die Anfrage von einer Adresse auf dieser Liste, wird Ihr API-Schlüssel geprüft; kommt sie von woanders, wird sie abgelehnt, auch wenn der Schlüssel stimmt.

Diese Prüfung ersetzt den API-Schlüssel nicht, sie kommt hinzu. Selbst wenn Ihr Schlüssel versehentlich in ein Repository gelangt oder vom Rechner eines Mitarbeiters abfließt, kann ihn niemand verwenden, der nicht auch von Ihrer Adresse ausgeht. Geprüft wird kein HTTP-Header, sondern die Adresse am anderen Ende der TCP-Verbindung; mit einem Header wie X-Forwarded-For lässt sich die Quelladresse nicht ändern.

Zwei Richtungen werden hier oft verwechselt. Bei der Liste, die wir in Proxy-Authentifizierung: User:Pass oder IP-Whitelist beschreiben, melden Sie Ihre Adresse Ihrem Proxy-Anbieter, damit Sie sich ohne Passwort mit dem Proxy verbinden können. In diesem Beitrag geht es um die Gegenrichtung: Sie melden Ihre Adresse dem Drittanbieter-Dienst, auf dessen Daten Sie zugreifen möchten. Der Mechanismus ist derselbe, das Gegenüber ein anderes.

In welchen Formen verlangen Dienste Ihre Ausgangs-IP?#

In der Praxis begegnen Ihnen drei Formen.

Pflichtregistrierung. Der Dienst gibt den Zugriff erst frei, wenn Ihre Adresse hinterlegt ist. Oft können Sie das nicht selbst erledigen: Sie eröffnen ein Support-Ticket, und die Adresse wird auf der Gegenseite von Hand eingetragen. Verbreitet ist diese Form bei Integrationen mit Banken und Behörden sowie bei manchen Marktplatz- und Versand-APIs. Bei einigen Diensten gilt die Regel nur für eine Umgebung, etwa für die Testumgebung, nicht aber für den Produktivbetrieb.

Optionale Einschränkung. Nicht der Dienst, sondern Sie schalten die Einschränkung ein. Viele Messaging- und E-Mail-Dienste haben im Dashboard ein Feld „Anfragen nur von diesen Adressen annehmen“. Hier ist die Fehlerursache meist eine vergessene Einstellung: Sie haben die Einschränkung selbst aktiviert, der Server ist umgezogen, und die alte Adresse steht noch in der Liste.

Die Gegenrichtung. Bei Abläufen wie Webhooks sendet der Dienst die Anfrage an Sie, und Sie führen die Allowlist: Sie tragen die Adressen, die der Dienst in seiner Dokumentation veröffentlicht, in Ihre eigene Firewall ein.

Die ersten beiden Formen stehen bei einem Anbieter oft nebeneinander: In der Testumgebung ist eine IP-Autorisierung Pflicht, im Produktivbetrieb nicht, und im Dashboard gibt es zusätzlich eine optionale Einschränkung, die Sie selbst einschalten. Viele Messaging- und Marktplatzanbieter führen diese Einschränkung in ihren Einrichtungsleitfäden als empfohlenen Sicherheitsschritt.

Die Regeln unterscheiden sich von Dienst zu Dienst und ändern sich mit der Zeit. Lesen Sie in der Entwicklerdokumentation des Dienstes nach, in welcher Umgebung, für wie viele Adressen und auf welchem Weg der Zugriff freigegeben wird.

Wann erscheint die Meldung „IP-Autorisierung erforderlich“?#

Die Meldung hat keine einheitliche Form. Dienste melden dieselbe Situation mit unterschiedlichen Codes:

• Eine ausdrückliche Meldung. Ein Text wie „IP-Autorisierung erforderlich“ oder „IP not allowed“ im Antwortkörper. Dieser Fall lässt sich am leichtesten erkennen.
• 403 Forbidden. Der Server hat die Anfrage verstanden, aber abgelehnt. Wie auch die MDN-Seite zu 403 festhält, ändert ein erneutes Senden der Zugangsdaten bei diesem Code nichts.
• 401 Unauthorized. Manche Dienste melden eine nicht passende Adresse mit demselben Code wie einen Fehler bei den Zugangsdaten. Wenn Sie Ihren Schlüssel dreimal erneuert haben und weiterhin 401 erhalten, sehen Sie sich die Adresse an.
• 503 oder Zeitüberschreitung. Wird schon an der Firewall gefiltert, also vor der Anwendung, kommt unter Umständen gar keine verwertbare Antwort. Manche Dienste dokumentieren genau dieses Verhalten: ein 503 in der Testumgebung, hinter dem in Wahrheit die fehlende IP-Autorisierung steckt.

Auch der umgekehrte Fall kommt vor: Nicht jedes 403 ist ein Adressproblem. Manche APIs lehnen Anfragen, denen ein Pflicht-Header fehlt, etwa ein User-Agent, mit demselben 403 ab. Bevor Sie die Adresse ändern, lesen Sie den Antwortkörper und vergleichen Sie Ihre Anfrage Header für Header mit dem Beispiel aus der Dokumentation. Wie Statuscodes allgemein zu lesen sind, steht in HTTP-Statuscodes beim Web Scraping.

Wie ermitteln Sie Ihre Ausgangs-IP?#

Die Adresse, die Sie dem Dienst melden, ist nicht die 192.168.x.x-Adresse aus den Netzwerkeinstellungen Ihres Rechners; sie gilt nur in Ihrem lokalen Netz. Der Dienst sieht die öffentliche Adresse, mit der Ihr Router oder Ihr Server ins Internet geht. So finden Sie die richtige Adresse:

1. Messen Sie auf der Maschine, die die Anfrage sendet. Läuft die Integration auf einem Server, ermitteln Sie die Adresse im Terminal dieses Servers, nicht im Browser Ihres Laptops.
2. Rufen Sie einen Echo-Dienst auf. curl https://api.ipify.org oder curl https://checkip.amazonaws.com liefert als Antwort nur die Adresse, die der Dienst sieht.
3. Messen Sie über den Weg, den die Anwendung nimmt. Geht Ihre Anwendung über einen Proxy oder ein Firmen-VPN hinaus, messen Sie über denselben Weg; eine direkte Messung zeigt eine andere Adresse.
4. Prüfen Sie IPv6. curl https://api64.ipify.org liefert Ihre IPv6-Adresse, wenn Ihr Anschluss eine hat. Unterstützt die Domain des Dienstes IPv6, geht Ihre Anfrage möglicherweise darüber hinaus; die gemeldete IPv4-Adresse wird dann gar nicht gesehen.
5. Wiederholen Sie die Messung. Führen Sie denselben Befehl nach einem Neustart des Routers und am nächsten Tag noch einmal aus. Ändert sich die Adresse, ist Ihr Anschluss dynamisch.

Warum passt die registrierte IP nicht mehr?#

Sie haben die richtige Adresse gemeldet, eine Zeit lang lief alles, dann nicht mehr. Mögliche Ursachen:

• Dynamische IP. Bei den meisten Privat- und Kleinbüroanschlüssen kann sich die Adresse ändern, sobald sich der Router neu verbindet oder die Lease-Zeit abläuft. Den gesamten Unterschied erklären wir in Statische oder dynamische IP.
• CGNAT. Teilt der Netzbetreiber dieselbe öffentliche Adresse unter vielen Kunden auf, gehört die Adresse, die Sie sehen, nicht Ihnen, und bei der nächsten Verbindung landen Sie womöglich auf einer anderen Adresse des Pools. Eine solche Adresse bei einer API zu registrieren heißt, auch anderen Kunden im selben Pool die Tür zu öffnen. Woran Sie es erkennen, steht in Was ist CGNAT?.
• Mobiler Hotspot oder vergessenes VPN. Eine vom Telefon geteilte Verbindung und ein auf dem Rechner vergessener VPN-Client schicken die Anfrage von einer völlig anderen Adresse hinaus.
• Mehrere Ausgangspunkte. Automatisch skalierte Container und Serverless-Funktionen ohne Anbindung an ein privates Netz können bei jedem Lauf mit einer anderen Adresse aus dem großen Pool des Cloud-Anbieters hinausgehen. Auch die automatisch vergebene öffentliche Adresse eines Cloud-Servers ändert sich bei den meisten Anbietern, wenn der Server gestoppt und wieder gestartet wird; dauerhaft wird sie erst, wenn Sie eine Adresse reservieren.

Vier Optionen für eine feste Ausgangs-IP#

Die dauerhafte Lösung ist eine Adresse, die Sie dem Dienst einmal melden und die sich nicht ändert. Dafür gibt es vier Wege; welcher passt, hängt davon ab, wo der Code läuft und welche Daten er transportiert.

Statische IP vom Internetanbieter. Es kommt kein neues System dazwischen, die Adresse Ihres vorhandenen Anschlusses wird festgelegt. Sie ist an diesen Anschluss gebunden; ein Entwickler im Homeoffice oder eine Filiale in einer anderen Stadt kann nicht von ihr ausgehen. Die Schritte zum Antrag stehen im Schwesterbeitrag im Abschnitt „Wie bekommt man eine feste IP?“.

Server mit fester IP. Wer eine dauerhaft laufende Aufgabe wie den nächtlichen Bestandsabgleich oder den Abruf von Bestellungen nicht auf dem Bürorechner, sondern auf einem Server mit reservierter Adresse betreibt, löst das Adressproblem und das Verfügbarkeitsproblem zugleich.

NAT-Gateway. Statt für jede Maschine eine eigene Adresse zu melden, binden Sie alle an einen gemeinsamen Ausgang. Laut der NAT-Gateway-Dokumentation von AWS wird einem öffentlichen NAT-Gateway beim Erstellen eine Elastic IP zugeordnet, und Ressourcen in privaten Subnetzen gehen über dieses Gateway ins Internet. Auch die Cloud-NAT-Übersicht von Google Cloud hält fest, dass manuell zugewiesene NAT-Adressen mit der Gegenseite geteilt werden können, und nennt als Beispiel Dienste, die Verbindungen nur von bekannten Adressen annehmen.

Statischer Proxy. Ihr Client geht über eine Ihnen zugewiesene, unveränderliche Proxy-Adresse ins Internet, und Sie melden dem Dienst diese Adresse. Ob Ihr Anschluss dynamisch ist oder hinter CGNAT liegt, spielt keine Rolle, denn der Dienst sieht die Adresse des Proxys. Im Gegenzug tritt ein Dritter in den Weg Ihres Datenverkehrs; wo das nicht hinnehmbar ist, klärt der nächste Abschnitt.

Warum wird bei Zahlungs-, Gesundheits- und E-Rechnungs-Integrationen kein Proxy verwendet?#

APIs für virtuelle POS-Systeme und Zahlungsinstitute, Abrechnungs- und Erfassungssysteme im Gesundheitswesen, E-Rechnungs- und E-Buchführungs-Integrationen sowie Meldedienste von Behörden bilden eine eigene Klasse. Bei diesen Integrationen empfehlen wir keinen Proxy eines Drittanbieters als Ausgangsadresse; das gilt auch für unser eigenes Produkt. Der richtige Weg ist eine statische IP von Ihrem Internetanbieter, die reservierte Adresse Ihres eigenen Servers oder ein NAT-Gateway in Ihrem Cloud-Konto. Die Gründe:

1. Die registrierte Adresse muss Ihnen gehören. Diese Institutionen führen die Adresse nicht als Sicherheitseinstellung, sondern als Nachweis: „Dieser Vorgang kam von diesem System dieses Unternehmens.“ Eine Proxy-Adresse gehört dem Anbieter und kann nach Ihrer Kündigung an einen anderen Kunden gehen. Ein Freigabe-Eintrag, dessen Löschung auf der Gegenseite vergessen wird, bringt den neuen Nutzer der Adresse Ihrem Konto einen Schritt näher.
2. Die Kette bekommt ein weiteres Glied. Bei HTTPS kann der Proxy den Inhalt der Anfrage nicht sehen: Die Verbindung entsteht über einen CONNECT-Tunnel, die Verschlüsselung bleibt zwischen Ihnen und der API. Trotzdem sieht der Proxy, an welchen Server Sie wann wie viele Daten senden, und bei einer Störung steht Ihr Zahlungs- oder Rechnungsablauf wegen eines Systems still, das Sie nicht kontrollieren.
3. Vertrag und Prüfung. Die Verträge dieser Integrationen und die Vorschriften, denen sie unterliegen, verlangen, dass Sie wissen und belegen können, über welche Systeme die Daten laufen. Lesen Sie die Vorgaben der Institution; viele schreiben ausdrücklich vor, dass die Adresse zu einem Anschluss oder Server Ihres Unternehmens gehört.
4. Es ist nicht nötig. Diese Systeme brauchen ohnehin einen Server im Dauerbetrieb. Wenn Sie einen Server haben, haben Sie auch eine feste Adresse.

Dieselbe Grenze gilt für jede Integration mit personenbezogenen Daten: Wo Kundenidentitäten, Gesundheits- oder Kartendaten fließen, sollte der Ausgangspunkt Ihre eigene Infrastruktur sein.

Wann ist ein statischer Proxy geeignet?#

Übrig bleiben Fälle ohne sensible Daten, in denen es schnell gehen soll:

• Test- und Entwicklungsumgebung. Der Dienst verlangt für seine Testumgebung eine Adresse, die Entwickler arbeiten aber im Homeoffice an dynamischen Anschlüssen. Statt für jeden Anschluss eine statische IP zu buchen, geht das Team über eine gemeinsame Proxy-Adresse hinaus, und diese wird dem Dienst gemeldet.
• Verteiltes Team, eine erlaubte Adresse. Ein Team, das dasselbe interne Tool aus drei Städten nutzt, muss dem Dienst nicht drei Adressen melden.
• Übergangszeit. Die Integration muss laufen, bis Ihr Antrag auf eine statische IP oder der Umzug auf einen Server abgeschlossen ist.
• Kleines Unternehmen hinter CGNAT. Der Anschluss arbeitet mit einer geteilten Adresse, und der Anbieter bietet in diesem Tarif keine statische IP an.

Lesen Sie in jedem Fall zuerst die Nutzungsbedingungen des Dienstes: Verlangt er, dass Anfragen direkt aus Ihrer eigenen Infrastruktur kommen, scheidet ein Proxy aus.

Achten Sie bei der Auswahl auf zwei Eigenschaften. Die Adresse muss Ihnen allein zugewiesen sein: Registrieren Sie eine geteilte Adresse bei einer API, kommen auch andere Nutzer derselben Adresse durch diesen Filter. Die Adresse muss statisch sein; die Adressen eines rotierenden Pools wechseln per Definition. Das Konzept erklären wir ausführlich auf unserer Seite Statischer Proxy. Bei Proxynet decken ISP-Proxy und Datacenter-Proxy diesen Bedarf: In beiden Fällen wird die Adresse nur Ihnen zugeteilt und ändert sich nicht, bis Sie sie abgeben. Der monatliche Grundpreis liegt bei 0,9 € für eine ISP-Adresse und bei 0,7 € für eine Datacenter-Adresse. Für API-Clients reicht meist eine Datacenter-Adresse; schränkt der Dienst Adressblöcke von Rechenzentren zusätzlich ein, wählen Sie eine ISP-Adresse.

Wie richten Sie mit einem statischen Proxy eine einzige Ausgangsadresse ein?#

1. Besorgen Sie sich eine statische Proxy-Adresse, die nur Ihnen zugewiesen ist.

2. Messen Sie die Ausgangsadresse mit dem folgenden Befehl. Diese Antwort ist die Adresse, die Sie dem Dienst melden; wiederholen Sie den Befehl im Abstand einiger Stunden und prüfen Sie, dass die Adresse gleich bleibt:

   bash

   curl -x http://user:pass@pr.proxynet.io:8000 https://api.ipify.org

3. Melden Sie diese Adresse dem API-Anbieter (Feld im Dashboard oder Support-Ticket). Je nach Dienst dauert es Minuten oder Stunden, bis der Eintrag aktiv ist; die Dauer entnehmen Sie der Dokumentation des Dienstes.

4. Tragen Sie den Proxy in Ihrem Client ein. Für Postman beschreibt Proxy-Einstellungen in Postman den Einstellungsdialog, für die Kommandozeile cURL mit Proxy verwenden und für den Anwendungscode Proxys in Node.js verwenden, jeweils Schritt für Schritt.

5. Rufen Sie die API-Adresse immer mit https:// auf. Die TLS-Verbindung im Tunnel wird direkt mit dem API-Server aufgebaut; Ihr Schlüssel und Ihre Daten gelangen nicht im Klartext zum Proxy.

Die Ausgangs-IP per Code überprüfen#

Sieht die Adresse einmal richtig aus und ändert sich danach, führt eine einzelne Messung in die Irre. Das folgende Skript sendet drei Runden Anfragen an zwei getrennte Echo-Dienste, öffnet für jede Messung eine neue Verbindung und vergleicht alle gesehenen Adressen mit der Adresse, die Sie dem Dienst gemeldet haben. Weil es bei einer Abweichung mit dem Code 1 endet, lässt es sich in Ihre Deployment-Pipeline (CI) einbinden. 203.0.113.10 ist eine für Dokumentationszwecke reservierte Beispieladresse; setzen Sie Ihre eigene ein.

import sys
import time

import requests

PROXY_URL = "http://user:pass@pr.proxynet.io:8000"
EXPECTED_IP = "203.0.113.10"  # die Adresse, die Sie dem API-Anbieter gemeldet haben
ECHO_URLS = ["https://api.ipify.org", "https://checkip.amazonaws.com"]
ROUNDS = 3


def egress_ip(url):
    # Jede Messung öffnet eine neue Sitzung: Wird ein offener Tunnel
    # wiederverwendet, bleibt eine wechselnde Ausgangsadresse unbemerkt.
    with requests.Session() as session:
        session.trust_env = False  # HTTP_PROXY / NO_PROXY aus der Shell sollen nicht mitmischen
        session.proxies = {"http": PROXY_URL, "https": PROXY_URL}
        response = session.get(url, timeout=15)
        response.raise_for_status()
        return response.text.strip()


def main():
    seen = set()
    for round_no in range(1, ROUNDS + 1):
        for url in ECHO_URLS:
            ip = egress_ip(url)
            seen.add(ip)
            print(f"Runde {round_no}  {url:<32} {ip}")
        time.sleep(2)

    if seen == {EXPECTED_IP}:
        print(f"OK: alle Anfragen gingen von {EXPECTED_IP} aus")
        return 0
    print(f"ABWEICHUNG: erwartet {EXPECTED_IP}, gesehen {sorted(seen)}")
    return 1


if __name__ == "__main__":
    sys.exit(main())

Wir haben das Skript über einen lokalen Test-Proxy ausgeführt: Jede der sechs Messungen öffnete einen eigenen CONNECT-Tunnel, und das Skript endete mit 0, wenn die Adresse der erwarteten entsprach, und mit 1, wenn nicht. Als wir das Passwort absichtlich falsch eingaben, warf Requests einen ProxyError mit 407; ein Fehler bei den Zugangsdaten fällt also nicht stillschweigend auf eine Direktverbindung zurück. Wenn Sie keinen Proxy nutzen (Anschluss oder Server mit statischer IP), genügt es, die Zeile session.proxies zu löschen; das Skript prüft dann die eigene Ausgangsadresse der Maschine.

In Node.js lässt sich dieselbe Prüfung ohne zusätzliches Paket durchführen. In aktuellen Node.js-Versionen liest das eingebaute fetch die Variable HTTPS_PROXY, wenn NODE_USE_ENV_PROXY=1 gesetzt ist (Einzelheiten in unserem Node.js-Beitrag):

const EXPECTED_IP = process.env.EXPECTED_IP ?? "203.0.113.10";
const ECHO_URLS = ["https://api.ipify.org", "https://checkip.amazonaws.com"];

const seen = new Set();
for (const url of ECHO_URLS) {
  const response = await fetch(url, { signal: AbortSignal.timeout(15_000) });
  if (!response.ok) throw new Error(`${url}: HTTP ${response.status}`);
  const ip = (await response.text()).trim();
  seen.add(ip);
  console.log(url.padEnd(32), ip);
}

const ok = seen.size === 1 && seen.has(EXPECTED_IP);
console.log(ok ? `OK: ${EXPECTED_IP}` : `ABWEICHUNG: erwartet ${EXPECTED_IP}, gesehen ${[...seen].join(", ")}`);
process.exitCode = ok ? 0 : 1;

NODE_USE_ENV_PROXY=1 HTTPS_PROXY="http://user:pass@pr.proxynet.io:8000" node check-egress-ip.mjs

Anwendungsfälle#

• Test einer Marktplatz-Integration: Die Testumgebung verlangt eine Adresse, das Team arbeitet verteilt. Das Team geht über eine statische Adresse hinaus; lesen Sie beim Wechsel in den Produktivbetrieb die Regel des Dienstes für diese Umgebung erneut. Weitere Szenarien aus dem Onlinehandel finden Sie auf unserer Seite E-Commerce-Proxy.
• Ortsabhängige API-Antworten testen: Um zu sehen, wie derselbe Endpunkt aus verschiedenen Ländern antwortet, werden feste Adressen mit wählbarem Land eingesetzt; den Aufbau beschreibt unsere Seite App-Tests.
• Versand-, Bestands- und Lieferanten-APIs: Greifen Lager, Buchhaltung und ein Operations-Team im Homeoffice auf denselben Dienst zu, verbinden sich entweder alle per VPN mit dem Büronetz oder gehen über eine gemeinsame statische Adresse hinaus.

Wenn die IP stimmt und der Fehler trotzdem bleibt#

• Der Eintrag ist noch nicht aktiv. Haben Sie die Adresse heute gemeldet, warten Sie die Bearbeitungszeit des Dienstes ab.
• Falsche Umgebung. Eine für die Testumgebung hinterlegte Adresse gilt nicht im Produktivbetrieb, und ein Produktivschlüssel gilt nicht in der Testumgebung. Prüfen Sie Domain und Schlüsselpaar zusammen.
• Sie gehen über IPv6 hinaus. Liefert api64.ipify.org eine IPv6-Adresse und unterstützt der Dienst IPv6, melden Sie entweder auch Ihre IPv6-Adresse oder zwingen Sie den Client auf IPv4 (curl -4).
• Fehlender Header. Auch ein fehlender User-Agent, Content-Type oder ein dienstspezifischer Header kann 403 liefern. Führen Sie die Beispielanfrage aus der Dokumentation unverändert aus und suchen Sie den Unterschied.
• Die Anfrage geht nicht von der erwarteten Maschine aus. Beim Dienst ist womöglich die Adresse des Servers registriert, während Sie die Anfrage von Ihrem eigenen Rechner in Postman testen; die geplante Aufgabe läuft vielleicht auf einem anderen Server. Führen Sie das Skript neben dem Prozess aus, der die Anfrage sendet.
• Proxy-Variable in der Shell. Ein Tool, das aus einem Terminal mit gesetztem HTTPS_PROXY startet, geht unbemerkt über den Proxy hinaus; eine als Dienst gestartete Anwendung sieht die Shell-Variable dagegen nicht.

Entscheidungshilfe#

Häufige Fragen#

Was bedeutet „IP-Autorisierung erforderlich“?#

Der Dienst hat die Adresse, von der Ihre Anfrage kam, mit den für Ihr Konto registrierten Adressen verglichen und keine Übereinstimmung gefunden. Ihr API-Schlüssel kann richtig sein; das Problem liegt bei der Adresse, von der die Anfrage ausging. Messen Sie Ihre Ausgangs-IP auf der Maschine, die die Anfrage sendet, und vergleichen Sie sie mit der registrierten Adresse.

Lässt sich eine API-Integration mit dynamischer IP betreiben?#

Verlangt der Dienst keine Adresse, ja, ohne jedes Problem. Verlangt er eine, ist ein dynamischer Anschluss keine dauerhafte Lösung: Bei jedem Adresswechsel müssen Sie den Dienst neu informieren, und in der Zwischenzeit steht die Integration. Besorgen Sie sich über eine der vier Optionen eine feste Ausgangsadresse.

Können bei einer API mehrere IP-Adressen hinterlegt werden?#

Das hängt vom Dienst ab. Manche erlauben mehrere Adressen oder einen Adressbereich, andere beschränken auf eine Adresse. Haben Sie zwei Ausgangspunkte (Server und Ersatzserver), melden Sie beide im selben Antrag.

Bekommt man mit einem VPN eine feste IP?#

Bei VPN-Apps für Privatkunden nein: Die Adressen werden von vielen Nutzern geteilt und können bei jeder Verbindung wechseln. Der eigene VPN-Server Ihres Unternehmens funktioniert dagegen, weil dessen Ausgangsadresse fest ist und Mitarbeiter aus der Ferne über das Büronetz hinausgehen.

Sieht der Proxy meinen API-Schlüssel, wenn ich einen statischen Proxy nutze?#

Wenn Sie die API mit https:// aufrufen, nein. Der Proxy sieht nur Namen und Port des Servers, mit dem Sie sich verbinden möchten, und leitet danach den verschlüsselten Tunnel weiter; Ihr Schlüssel und die Antworten liegen im Tunnel. Bei einer API, die über http:// aufgerufen wird, geht alles im Klartext hinaus; nutzen Sie eine solche API weder mit noch ohne Proxy.

Was mache ich mit dem IP-Eintrag bei der API, wenn ich den Proxy abgebe?#

Lassen Sie ihn noch am selben Tag löschen. Auch wenn die Adresse nur Ihnen zugewiesen war, kann sie nach Vertragsende an einen anderen Kunden gehen, und solange der Eintrag beim Dienst besteht, bleibt diese Adresse für Ihr Konto freigegeben. Dieselbe Regel gilt für die reservierten Adressen von Servern, die Sie abschalten.

Fazit#

Ein IP-Autorisierungsfehler ist kein Codefehler, sondern eine nicht passende Adresse: Der Dienst kennt eine Adresse, Ihre Anfrage geht von einer anderen aus. Messen Sie zuerst Ihre Ausgangs-IP auf der Maschine, die die Anfrage sendet, und legen Sie die Adresse dann fest. Bei Integrationen mit sensiblen Daten sollte diese Adresse die statische IP Ihres eigenen Anschlusses, Ihr eigener Server oder ein NAT-Gateway in Ihrem Cloud-Konto sein; bei Zahlung, Gesundheit und E-Rechnung schalten Sie keinen Dritten dazwischen. Für Testumgebungen, verteilte Teams und Übergangszeiten reicht eine Ihnen zugewiesene statische Adresse; die Optionen finden Sie bei unseren Proxy-Diensten.