PullMD Teil 13: Eine alte Regel – Einfach erklärt
Im letzten Teil hatte ich aufgehört mit: der Server ist fertig, aber auf der anderen Seite lässt mich keiner durch. Ich wartete. Vier Tage lang passierte nichts.
Etwas nagte
Dann begann etwas zu nagen. Am Abend hatte auf der Diskussionsseite bei GitHub jemand eine ausführliche Erklärung gepostet, warum das Problem erledigt sei. Seine Theorie: Claude prüft vor dem ersten Kontakt die Adresse des Servers. Wenn die Adresse auf ein privates Netzwerk zeigt, wird die Verbindung verworfen, bevor sie Anthropic überhaupt verlässt. Das passte sauber auf einen bestimmten Server-Typ. Aber nicht auf meinen: mein Server stand hinter Cloudflare (einem Schutzdienst, der vor der eigentlichen Website steht), mit gültiger öffentlicher Adresse.
Noch in derselben Nacht schrieb ich einen sachlichen Kommentar:
“Posting anyway because the explanation maps cleanly onto fbs.synology.me but doesn’t seem to fit my setup, and I’d like a sanity check before this is considered fully resolved.”
Sinngemäß: eure Erklärung passt nicht auf mein Setup. Bitte nochmal hinschauen, bevor das als erledigt gilt.
Zwei Protokolle, zwei Befunde
Am nächsten Morgen habe ich die Protokolldateien meines eigenen Servers geholt. Protokolldateien sind so etwas wie ein Gästebuch an der Haustür: jeder Besucher hinterlässt einen Eintrag. Was mein Gästebuch zeigte: komplett leer. Kein einziger Besucher von Anthropics Seite war jemals bis zu meinem Server durchgekommen. Der Server schwieg nicht. Er wurde gar nicht erst gefragt.
Also lag der Block weiter vorne. Vor meinem Server steht Cloudflare als Schutzdienst: eine Art Türsteher, der entscheidet, wer rein darf. Was der Türsteher abweist, taucht im Gästebuch des Servers nie auf. Claude hat mich dann in der Cloudflare-Oberfläche zu einem zweiten Protokoll gelotst: dem Sicherheitsprotokoll des Türstehers selbst.
Da standen sie. Anfragen aus Anthropics Adressbereich, jede einzelne geblockt, immer von derselben Regel. Dieses zweite Protokoll hatte ich beim ersten Analysieren schlicht nicht gefunden und nicht weiter hinterfragt. Durch die Diskussion auf GitHub sah ja ohnehin alles nach „nicht mein Problem“ aus.
Bei fremden Problemen predige ich sonst immer: schaut in die Logs! Diesmal hat es mich selbst erwischt.
Die Regel, die sich selbst überlebt hatte
Die Ursache war eine Sicherheitsregel, die ich selbst geschrieben hatte. Vor langer Zeit. Damals wollte ich bestimmte Dienste nur aus Deutschland erreichbar machen. Die Regel war simpel: wer nicht aus Deutschland kommt, wird abgewiesen. Sie galt für die gesamte Zone, also für alles unter derselben Domain.
Die Dienste, für die ich das eingerichtet hatte, nutze ich gar nicht mehr. Aber die Regel lief still weiter. Als ich meinen Markdown-Service unter demselben Schirm aufgehängt hatte, fiel er automatisch unter diese Regel. Claude versucht, meinen Server aus den USA zu erreichen. Die USA sind nicht Deutschland.
Das Signal aus Teil 12 hatte trotzdem gestimmt: zwei unabhängige Server versagten identisch, also lag das Problem nicht im Code. Aber beide Server saßen hinter derselben Cloudflare-Zone. Die Regel hat genau das getan, wofür ich sie geschrieben hatte. Nur der Rest hatte sich verändert.
Die Korrektur
Der Fix war klein: eine Ausnahme-Regel für den Adressbereich von Anthropic, ganz oben in der Regelkette. Danach funktionierte der Anmeldevorgang aus Teil 12 sofort.
Am Nachmittag habe ich auf der GitHub-Diskussion einen Korrekturkommentar geschrieben:
“Update — happy to confirm the fix worked on my end. … For the record: the actual culprit on my side was a country-based GeoBlocking custom rule I had set up long ago for an unrelated service —
(ip.geoip.country ne "DE")— which I’d completely forgotten about.”„Der eigentliche Verursacher war eine alte Blockierregel für einen Dienst, den ich gar nicht mehr nutze. Völlig vergessen.“
Und eine Notiz für alle, die auf dasselbe stoßen könnten:
“Worth flagging for anyone else hitting this: check custom WAF rules with country/ASN/IP-range conditions, not just Bot Fight Mode. An old rule that was reasonable when you wrote it can quietly catch new legitimate traffic.”
„Prüft eure eigenen Sicherheitsregeln. Eine alte Regel, die beim Schreiben sinnvoll war, kann still neuen, erwünschten Verkehr abfangen.“
Den Fehler offen eingestanden, damit der nächste mit demselben Problem ihn beim Suchen findet.
Zwei Releases an einem Tag
Die Pipeline war frei. Was noch ausstand, passte in einen einzigen Tag.
Die Rezept-Engine war schon fünf Tage vorher veröffentlicht worden. Ein Nutzer hatte gemeldet, dass bei einer bestimmten Nachrichtenseite Absätze verschluckt wurden. Daraus wurde eine Konfigurationsdatei, die pro Website beschreibt, wie der Service mit ihr umgehen soll. Wie eine Rezeptsammlung: für jede schwierige Website ein eigenes Rezept. Ehrliche Limitation: Seiten mit Cookie-Sperren löst das System bewusst nicht.
Das erste Release des Tages war der Anmeldevorgang aus Teil 12. Fertig im Regal, weil die Tür auf der anderen Seite nicht aufging. Jetzt ging sie auf.
Das zweite war eine formatierte Vorschau. Ein Nutzer hatte auf GitHub darum gebeten:
“The web GUI currently shows the fetched result as raw Markdown source. Would be great to have an option to view it rendered as actual Markdown in the browser too.”
„Es wäre toll, den Text nicht nur als rohe Quelle zu sehen, sondern auch hübsch formatiert.“
An einem Nachmittag erledigt. Vor dem Schließen des Tickets habe ich noch einen menschlichen Kommentar hinterlassen: kurze Notiz, dass ich die Idee gut fand. Bei einem nett gestellten Wunsch kostet das fünf Minuten. Für den Menschen auf der anderen Seite macht es den Unterschied zwischen „jemand hat das gelesen“ und „der Bot hat geantwortet“.
Der Docker-Fehler, den niemand sah
Ein Detail am Rand, das zeigt, wie Fehler unsichtbar werden. Docker ist ein System, das Programme in versiegelten Boxen (Containern) verpackt und verteilt. Wenn man eine bestimmte Version herunterlädt, wählt man sie über ein Etikett. Das Etikett :latest soll auf “die aktuellste empfohlene Version” zeigen.
Nach dem Release zeigte :latest auf die falsche Version. Das Veröffentlichungssystem hatte automatisch jede neue Version als “die neueste” markiert, obwohl der Plan war, Nutzern der alten Hauptversion noch eine Übergangszeit zu geben.
Was den Fehler so lange unsichtbar machte: eine veraltete Notiz im Projekt-Gedächtnis von Claude behauptete, das Etikett stehe noch auf der alten Version. Nie überprüft. Wenn die Notiz sagt, alles ist in Ordnung, und man nie nachschaut: natürlich sieht man nichts.
Was bleibt
Vier Tage Stillstand, und die Ursache lag die ganze Zeit auf der eigenen Seite. Nicht die Plattform hat geblockt. Es war eine vergessene Sicherheitsregel, geschrieben für einen Zweck, der längst weggefallen war. Sie hat still weitergearbeitet und neuen Verkehr abgefangen, der nichts mit dem ursprünglichen Zweck zu tun hatte.
Die Lektion: wenn etwas nach einem Problem auf der anderen Seite aussieht, erst die eigene Seite prüfen. Und ja: in die Logs schauen. Alle Logs.
Danach wurde es erst mal ruhiger. Der nächste größere Umbau kam einen Monat später. Im Juni landete Microsofts MarkItDown in PullMD, als Helfer für PDF, Word, PowerPoint und andere Dokumentformate. Drei Teile davon habe ich gleich wieder herausgezogen. Einer hätte Audio stillschweigend an Googles Schnittstelle geschickt. Darum geht es in Teil 14.
Teil 13 von 15 der PullMD Serie.
← PullMD Teil 12: Spec-Compliant ist nicht genug | PullMD Teil 14: Microsofts MarkItDown integriert — und drei Teile wieder rausgerissen →