TL;DR
TL;DR: Seit dem Wechsel auf Dual-Stack sprach der Edge-Proxy die Mandanten-Proxys auch über IPv6 an. Die vertrauten weitergereichten Client-Adressen aber nur aus dem IPv4-Pod-Netz. Über IPv6 erschien deshalb jeder Besucher mit der Adresse des Edge-Proxys, die Intrusion Detection sperrte sie, und ihr Paketfilter verwarf allen Verkehr dieses Pods. Der Fix war eine Zeile in der Vertrauensliste.
Was passiert ist
Die Umstellung selbst lief ruhig. Die Dienste im Cluster bekamen neben ihrer IPv4- eine IPv6-Adresse, die Endpunkte tauchten in beiden Familien auf, und eine Weile war alles grün. Eine halbe Stunde später kamen die ersten Fehler. Nicht auf einer Seite, sondern auf allen. Über IPv4 antwortete der Edge-Proxy mit 502, über IPv6 kam oft gar keine Verbindung zustande. Immer nur ein Teil der Anfragen, mal ein Viertel, mal die Hälfte.
Ein Pod von zweien
Der erste Hinweis stand im Access-Log. Der Edge-Proxy läuft mit zwei Pods, und alle Fehler kamen aus genau einem davon. Der zweite war sauber. Die fehlerhaften Anfragen hatten eine weitere Gemeinsamkeit: Sie gingen alle an IPv6-Adressen der Backends und liefen nach rund drei Sekunden in ein Verbindungs-Timeout.
Auf dem Knoten zeigte die Nachbartabelle dann das eigentliche Bild. Jeder Pod hatte dort einen erreichbaren Eintrag, nur die IPv6-Adresse des kaputten Edge-Pods stand auf INCOMPLETE. Er beantwortete keine Neighbour Discovery mehr. Antworten auf seine eigenen Verbindungen erreichten ihn deshalb nicht, und eingehende IPv6-Verbindungen, die bei ihm landeten, brachen ab.
Ein neuer Pod mit demselben Fehler
Die naheliegende Reparatur war, den Pod zu ersetzen. Der neue Pod war sofort genauso kaputt, mit einer frischen Adresse. Damit war klar, dass es nicht an diesem einen Pod lag. Irgendetwas sorgte dafür, dass neue Edge-Pods im Netz nicht mehr existierten.
Die Antwort stand in der Sperrliste der Intrusion Detection. Dort standen die IPv6-Adressen beider Edge-Pods, der alte und der gerade gestartete. Ihr Paketfilter verwarf allen Verkehr dieser Adressen, die Neighbour Discovery eingeschlossen, und genau deshalb sah es auf dem Knoten nach einem Netzwerkfehler aus.
Warum ausgerechnet die eigene Adresse
Die Mandanten-Proxys sitzen hinter dem Edge-Proxy. Ihr direkter Gesprächspartner ist also immer ein Edge-Pod, und die echte Client-Adresse steht im Header X-Forwarded-For. Diesem Header vertrauen sie aber nur, wenn die Verbindung aus dem Pod-Netz kommt:
trusted_proxies static <ipv4-pod-cidr>
client_ip_headers X-Forwarded-For
Bis zur Umstellung kam jede Verbindung über IPv4, und das passte. Danach kam ein Teil über IPv6, aus einem Netz, das nicht auf der Liste stand. Für diese Verbindungen ignorierten die Mandanten-Proxys den Header und meldeten den Edge-Pod als Client. Jede auffällige Anfrage aus dem Internet, jeder Scanner und jeder Fehlversuch landete damit auf dem Konto des eigenen Edge-Proxys, bis die Intrusion Detection ihn sperrte.
Der Kommentar direkt über dieser Zeile beschrieb das Problem schon vor Monaten. Ohne die Vertrauensliste, stand dort, wäre die Client-Adresse der interne Hop, und die Intrusion Detection würde den Hop sperren. Er war nur für IPv4 geschrieben.
Wie es wieder lief
Zuerst lief der ganze Verkehr über den einen Edge-Pod, der noch nicht gesperrt war. Danach gingen die Dienste zurück auf eine Adressfamilie, damit kein weiterer Pod in dieselbe Falle laufen konnte. Der eigentliche Fix war eine Erweiterung der Vertrauensliste um das IPv6-Pod-Netz. Dieselbe Lücke hatten zwei Schutzregeln weiter unten, die interne Aufrufer erkennen sollten, und auch dort fehlte das IPv6-Netz.
trusted_proxies static <ipv4-pod-cidr> <ipv6-pod-cidr>Die Lehre
Wer die Adressfamilien eines Clusters ändert, ändert damit stillschweigend jede Liste, die Adressbereichen vertraut. Deshalb lohnt es sich, vor dem Wechsel auf Dual-Stack alle diese Stellen zu suchen, von den weitergereichten Client-Adressen über interne Allowlists bis zur Ratenbegrenzung und den Ausnahmen der Intrusion Detection. Eine Liste, die nur eine Familie kennt, macht die andere sonst zum Fremden.
Häufige Fragen
Wie findet man solche Stellen vor der Umstellung?+
Am einfachsten mit einer Suche nach jedem Adressbereich, der als vertrauenswürdig gilt, in Konfiguration, Charts und Policies. Jede Fundstelle braucht dann beide Adressfamilien oder eine Begründung, warum eine genügt. Damit das so bleibt, hilft ein Test, der eine Anfrage über IPv6 durch die ganze Kette schickt und prüft, welche Client-Adresse am Ende ankommt.
Warum nicht einfach das Pod-Netz in der Intrusion Detection ausnehmen?+
Das hätte die Ursache nur verdeckt. Die Mandanten-Proxys hätten weiterhin jeden Besucher als Edge-Proxy gemeldet, sodass echte Angreifer hinter dieser Adresse verschwunden wären. Der Fix gehört deshalb dorthin, wo die echte Client-Adresse verloren ging, also in die Vertrauensliste.
Warum sah das nach einem Netzwerkfehler aus?+
Der Paketfilter der Intrusion Detection verwarf auch die Neighbour Discovery. Auf dem Knoten wirkte der gesperrte Pod deshalb wie einer mit kaputtem Interface, und erst die Sperrliste zeigte, dass dahinter eine Sicherheitsentscheidung stand.
Fazit
Ausgesperrt hat sich die Plattform nicht durch einen Fehler im Netz, sondern durch eine Vertrauensliste, die eine Adressfamilie nicht kannte. Deshalb sah das Fehlerbild nach Netzwerk aus, obwohl es eine Sicherheitsentscheidung war. Am meisten beschäftigt mich, dass der Kommentar in der Konfiguration genau diesen Ausfall vorhergesagt hatte, nur eben für die Adressen, die es gab, als er geschrieben wurde.
Weiter geht es mit Teil 7: Erst die Freigabe, dann der Schalter.
Ich prüfe deine Vertrauenslisten, bevor ein Wechsel auf Dual-Stack sie umgeht.
Dabei gehe ich jede Stelle durch, die Adressbereiche als vertrauenswürdig einstuft, von weitergereichten Client-Adressen und internen Allowlists bis zur Ratenbegrenzung und den Ausnahmen der Intrusion Detection, und zwar für beide Adressfamilien.
Statt Beratung auf Papier begleite ich die Umstellung im Betrieb, bis der erste ruhige Tag da ist.
Über den Autor
Kai Ole Hartwig
Programmiert seit 2002 – autodidaktisch gelernt, 2012 mit KO-Web selbständig gemacht. Über 100 Projekte, Fokus auf Security, Performance, Automatisierung und Qualität. Heute freiberuflich: DevSecOps-Beratung, Schulungen und Softwareentwicklung.