worm's eye-view photography of ceiling

Matrix vs Ntfy – Fehlersuche à la carte

Ich betreibe einen kleinen Matrix Homeserver. Einer der Gründe ist einfach der Preis von Speicher, da jener am Smartphone einfach viel teurer ist, als ein paar Festplatten in meinem Server. Durch das ‚umlagern‘ der ganzen Messenger auf den Server hatte ich kurzerhand um die 20 GB Speicher auf dem Androiden wieder frei gemacht und nur noch eine App.

Aber nun zum versprochenen Problem. Mein Server war installiert und ich begann die Kiste nach meinem Gutdünken mit Bridges zu erweitern – auch mit einem eigenen Push Server, da ich nicht unbedingt meine eigenen Apps bauen wollte, nur um mit dem Google Push Service zu interagieren. Die Installation lief und alles sah gut aus, außer dass der Matrix client nie aufgeweckt wurde. Eigene Push-Mitteilungen, die ich als Alarme nutzte, kamen sehr wohl an. Ich muss zugeben, Anfangs hatte mich die Ruhe nicht wirklich gestört, bis es einfach mal zu ruhig war und ich dieses ‚hier stimmt etwas nicht‘-Gefühl sich in der Magengegend manifestierte.

Unser Container produzierte brav Logfiles – und da war auch ein Hinweis, der mich alles nur nicht erleichterte:
Mar 18 23:30:14 matrix matrix-synapse[2213]: 2023-03-18 22:30:14,267 - synapse.push.httppusher - 432 - WARNING - httppush.process-17 - Failed to push event $bLGuzRj3t4p6Z6h16aTmfw9YA5gEhZZ0fZOebFToL04 to @user:domain/im.vector.app.android/https://ntfy.domain/upv5aFQWe5uAHe?up=1: DNS lookup failed: no results for hostname lookup: ntfy.domain.

Was war da los? War das Docker-Netzwerk im Eimer? War der DNS down oder nur falsch eingestellt? Ich hab‘ mir gleich einmal eine Shell an den Container geheftet und mit einigermaßen Frust festgestellt, dass der Container weder ‚ping‘ noch anderes Netzwerk-Werkzeug enthielt (was ja eigentlich nicht schlecht ist!). Nach einigen Geräuschemissionen fand ich dann aber doch die curl Binary und konnte versuchen, eine Nachricht an den Push Service abzusetzen…. Erfolgreich?

Okay – dann hatte die Meldung offenbar nichts mit dem DNS zu tun und hatte die gleiche Glaubwürdigkeit wie die Aussage eines Politikers. Demnach war der Schuldige definitiv der Synapse Server und ich hatte absolut keine Lust voreilig in dessen (teilweise echt furchteinflößendem) Code zu wühlen. Also nahm ich mir als erstes das Twisted Framework vor, welches dazu benutzt wurde den Service zu programmieren. Ein DNS Test Script war eine einfache Möglichkeit zu sehen, woran es liegen könnte. Zwei Sekunden und einen Wutschrei später war auch Twisted als Unschuldig außen vor.

Mit einer frischen Tasse Tee hatte ich mich dann ans Suchen und Code lesen gemacht und nach Stunden einen Hinweis in der Config gefunden:


# Prevent outgoing requests from being sent to the following blacklisted IP address
# CIDR ranges. If this option is not specified then it defaults to private IP
# address ranges (see the example below).
#
# The blacklist applies to the outbound requests for federation, identity servers,
# push servers, and for checking key validity for third-party invite events.
#
# (0.0.0.0 and :: are always blacklisted, whether or not they are explicitly
# listed here, since they correspond to unroutable addresses.)
#
# This option replaces federation_ip_range_blacklist in Synapse v1.25.0.
#
# Note: The value is ignored when an HTTP proxy is in use
#
#ip_range_blacklist:
# - '127.0.0.0/8'
# - '10.0.0.0/8'
# - '172.16.0.0/12'
# - '192.168.0.0/16'
# - '100.64.0.0/10'
# - '192.0.0.0/24'
# - '169.254.0.0/16'
# - '192.88.99.0/24'
# - '198.18.0.0/15'
# - '192.0.2.0/24'
# - '198.51.100.0/24'
# - '203.0.113.0/24'
# - '224.0.0.0/4'
# - '::1/128'
# - 'fe80::/10'
# - 'fc00::/7'
# - '2001:db8::/32'
# - 'ff00::/8'
# - 'fec0::/10'

# List of IP address CIDR ranges that should be allowed for federation,
# identity servers, push servers, and for checking key validity for
# third-party invite events. This is useful for specifying exceptions to
# wide-ranging blacklisted target IP ranges - e.g. for communication with
# a push server only visible in your network.
#
# This whitelist overrides ip_range_blacklist and defaults to an empty
# list.
#
#ip_range_whitelist:
# - '192.168.1.1'

Mein ntfy Service war in meiner DMZ und wurde auch (erfolgreich) von anderen Diensten verwendet. Das setzte ihn jedoch auf die Blockliste von Synapse und verursachte somit das Problem. Ein Einfacher Eintrag in der Whitelist hat die Sache dann erledigt. Ich fühlte mich für einen Moment echt großartig, das Problem gelöst zu haben… bis die Benachrichtigungen über ungelesene Nachrichten bei mir wieder eintrudelten. Vermisse ich die Ruhe nachdem ich den Fehler repariert hatte? Manchmal.

Author:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert