d.vinci läuft hinter Akamai als WAF/CDN, die Hintergründe stehen im Artikel Unterauftragnehmer Akamai. Dieser Artikel richtet sich an eure IT und beschreibt, was sich technisch ändert und was ihr ggf. anpassen müsst. Ist euer System noch nicht umgestellt, sprechen wir den Termin vorher mit euch ab. Läuft es auf einer Hauptdomain ohne Subdomain (z. B. example-karriere.de), sind dafür DNS-Änderungen bei euch nötig. Die Einträge schicken wir euch.
Auf einen Blick
- Eure d.vinci-Domain löst auf wechselnde Akamai-IPs auf (geringe TTL, je nach Standort unterschiedlich). Diese IPs nutzen auch andere Akamai-Kunden, und eine feste Liste gibt es nicht.
- Freigaben und Routing deshalb nach Hostname, nicht nach IP.
- TLS 1.2 und 1.3. Zertifikate: unsere Wildcard-Zertifikate, bei eigenen Domains automatisch über Let's Encrypt.
- HTTP-Header-Namen kommen kleingeschrieben an.
- Anfragen ohne Antwort nach 10 Minuten bricht Akamai ab und zeigt eine eigene Fehlerseite.
Eigene Domain
Läuft euer d.vinci unter einer eigenen Domain, muss sie per CNAME auf uns zeigen. Ein A-Record auf eine feste IP funktioniert mit Akamai nicht. Alle Einträge und typischen Fehler stehen in Eigene Domain: technische Einrichtung.
Firewall und Proxy
- Gebt eure d.vinci-Domain per Hostname frei (SNI oder URL-Kategorie).
- FQDN-Objekte, die die Firewall in IPs auflöst, laufen der schnell wechselnden Auflösung hinterher. Achtet darauf, wo aufgelöst wird (Client oder Proxy) und dass die TTL nicht überschrieben wird.
- Bei Cloud-Proxys wie Zscaler gilt dasselbe für App-Segmente und Health-Checks, die auf aufgelöste IPs setzen. Sie fallen sporadisch aus.
- Statische Routen oder IP-Listen für alte d.vinci-IPs entfernt ihr am besten.
IP-Zugriffsregeln
Die IP-Zugriffsregeln in d.vinci prüfen weiterhin eure öffentliche Quell-IP. Das gilt auch für die Anmeldung per SSO.
Symptom: Einige Nutzer oder Standorte werden abgewiesen, oft im Homeoffice oder nur sporadisch.
Ursache: Split-Routing. Ihr leitet Traffic nach Ziel-IP auf unterschiedliche Ausgänge, und die Akamai-IPs fallen aus dem Pfad mit der freigegebenen Quell-IP. Typisch sind:
- Split-Tunnel-VPN
- SSE/SASE-Proxys wie Zscaler, Netskope oder Prisma Access
- Policy-Based Routing oder NAT
- SD-WAN
Lösungen:
- Traffic zu d.vinci per Hostname immer über denselben Ausgang mit fester Quell-IP leiten.
- Die IP-Zugriffsregeln durch Conditional Access im SSO ersetzen, siehe Single Sign-on einrichten am Beispiel Microsoft Entra ID. Den Passwort-Login erst abschalten, wenn SSO nachweislich funktioniert.
- Die IP-Zugriffsregeln entfernen. Das senkt das Schutzniveau.
Eingrenzen: Schickt uns die Uhrzeiten von 3–5 fehlgeschlagenen Versuchen. Wir nennen euch dann die Quell-IP, die bei uns angekommen ist.
Alle ausgesperrt: Ein d.vinci-Admin kann die Regeln unter Grundeinstellungen → Sicherheit selbst entfernen. Sonst macht das unser Support, aber nur auf Anfrage von Weisungsberechtigten.
Schnittstellen
- Weiterleitungen: Wenn sich die Adresse ändert und die alte nur noch weiterleitet, folgen Power BI und Power Apps der Weiterleitung nicht. Tragt dann die neue URL ein und hinterlegt die Anmeldedaten neu (bei Power BI im Power BI Service).
- Header-Namen: Sie kommen kleingeschrieben an (
odata-version), auch über HTTP/1.1. Clients, die Groß- und Kleinschreibung unterscheiden, scheitern daran, z. B. der SSIS OData Connection Manager. Nutzt dann stattdessenMicrosoft.OData.Clientoder Power Query.
Penetrationstests
Meldet Pentests gegen euer d.vinci bitte vorher bei uns an, mit Zeitraum und Quell-IPs. Unangemeldet blockiert die WAF den Test, und wir behandeln ihn als Angriff.
An den Support schicken
Mit diesen Angaben finden wir die betroffene Anfrage in unseren Logs und sehen, ob die WAF, das Netzwerk oder d.vinci selbst die Ursache ist:
- die Referenznummer der Akamai-Fehlerseite (
Reference #…), möglichst zeitnah - Uhrzeit mit Zeitzone und die URL
- die Fehlermeldung im Wortlaut oder als Screenshot
- bei Schnittstellen das betroffene Programm