Messnetz (Sonar)

Die Aussensicht auf die eigene Infrastruktur – freiwillig, begrenzt, protokolliert.

NODE64 sieht dein System von innen. Manche Fragen lassen sich von innen aber nicht beantworten: Ist der Port wirklich von aussen erreichbar? Wie lange braucht ein Paket dorthin? Antwortet der Nameserver von überall gleich?

Dafür gibt es Sonar: ein Messnetz aus Geräten, deren Betreiber ausdrücklich zugestimmt haben.

Wie es funktioniert #

Du beauftragst eine Messung gegen ein Ziel, das dir gehört. Eine Sonde – ein anderes teilnehmendes Gerät oder ein NODE64-Messknoten – führt sie aus und meldet das Ergebnis zurück. Du siehst Laufzeit, Verlust, Route oder Zertifikatsdaten.

Was gemessen werden kann:

Ziele: nur deine eigenen #

Bevor du etwas messen darfst, musst du zeigen, dass es dir gehört. Zwei Wege:

• Über ein Gerät: Die öffentliche Adresse eines angebundenen Geräts gilt als nachgewiesen.
• Über DNS: Du hinterlegst einen TXT-Eintrag mit einem Token, den wir dir geben. Wer den Eintrag setzen kann, kontrolliert die Zone.

Dazu gibt es eine kurze, von uns gepflegte Liste kuratierter Ziele – öffentliche DNS-Resolver und unsere eigenen Messknoten, deren Betreiber mit Messverkehr rechnen. Die kannst du ohne Nachweis übernehmen; sie taugen als Referenz („ist meine Leitung schlecht oder das Ziel?").

Fremde Ziele sind gesperrt. Sonar ist kein Scanner, und die Port-Messung geht ausschliesslich gegen nachgewiesen eigene Systeme – ein einzelner Port, ein einzelner Verbindungsversuch.

Teilnehmen #

Die Teilnahme ist freiwillig und je Gerät abschaltbar – standardmässig ist sie aus. Schaltest du sie ein, führt dein Gerät gelegentlich Messungen für andere aus. Drei Dinge solltest du wissen:

1. Der Messverkehr geht von deinem Anschluss aus. Nicht von einem NODE64-Rechenzentrum. Wer die Zieladresse betreibt, sieht deine IP.
2. Du siehst jeden Auftrag, den dein Gerät übernommen hat – Messart, Ziel, Zeitpunkt, Ergebnis. Wer ihn beauftragt hat, siehst du nicht; umgekehrt sieht der Auftraggeber deine Adresse nicht.
3. Dein Gerät hat harte Obergrenzen, die im Agenten selbst stecken. Sie gelten auch dann, wenn der NODE64-Server etwas anderes verlangt.

Abschalten geht jederzeit im Dashboard – oder lokal in der Konfiguration mit NODE64_SONAR=false.

Grenzen und Schutz #

Der Tarif begrenzt gar nichts am Messnetz — nicht die Zahl der Knoten, nicht die der gleichzeitigen Messungen, nicht die Sonden je Messung. Am Tarif hängt nur noch, wie lange die Ergebnisse aufbewahrt werden — und das ist keine Grenze, sondern eine Löschzusage.

Ein Messnetz ohne Kontrollen wäre trotzdem ein verteiltes Angriffswerkzeug. Was den Durchsatz stattdessen regelt, gilt für alle Konten gleich, unabhängig vom Tarif:

• Keine internen Ziele. Private Bereiche, Loopback, Cloud-Metadaten sind ausgeschlossen; nach der DNS-Auflösung wird erneut geprüft.
• Mehrstufige Deckel je Ziel, je Sonde, je Konto und global. Der Deckel je Ziel wirkt über alle Nutzer hinweg – er verhindert, dass sich viele harmlose Einzelmessungen zu einer Last summieren.
• Enges Paketprofil: kleine Pakete, feste Zeitüberschreitungen, begrenzte Hop-Zahl. Kein Flood, keine grossen Nutzlasten, keine Portbereiche.
• Automatische Missbrauchserkennung: Wer auffällig viele verschiedene Ziele im selben Netz misst, wird gedrosselt.
• Lückenloses Protokoll. Jede Messung und jede Ablehnung wird festgehalten.
• Meldeweg für Zielbetreiber: node64.de/de/sonar erklärt den Verkehr und nennt die Adresse zum Austragen.

Von aussen prüfen #

Der häufigste Anwendungsfall steht direkt am passenden Befund: Wenn NODE64 vermutet, dass ein Port von aussen erreichbar ist, findest du dort Jetzt von aussen prüfen. Ein Messknoten klopft an – und aus einer Vermutung wird ein Messwert.

Pfad-MTU: die Messung, die kein Ping ersetzt #

Eine zu kleine Pfad-MTU merkt niemand am Ping. Kleine Pakete kommen durch, die Verbindung steht, alles sieht gesund aus. Erst wenn ein grosses Paket unterwegs ist – der TLS-Handshake mit dem Zertifikat, ein Upload, ein VPN-Tunnel –, bleibt die Verbindung hängen.

Die Messart Pfad-MTU sucht mit gesetztem DF-Bit die grösste Paketgrösse, die den ganzen Weg übersteht. Sie liefert drei mögliche Antworten:

Der dritte Fall ist der Grund, warum es diese Messart gibt. Er ist die Ursache hinter Verbindungen, die stehen und trotzdem nichts übertragen, und er ist mit keinem anderen Werkzeug so einfach zu sehen.

Werte zum Einordnen: 1500 Ethernet ohne Zusätze · 1492 PPPoE (DSL) · rund 1420 WireGuard · 1280 IPv6-Mindestwert.

Was du für andere misst #

Wenn deine Sonde teilnimmt, führt sie Aufträge anderer Konten aus – das ist der Sinn der Sache: Man misst mit fremden Augen, also stellt man auch die eigenen zur Verfügung.

Was dabei über deinen Anschluss geht, ist eng begrenzt:

• Nur die Messarten aus der Liste oben. Was nicht einkompiliert ist, existiert für die Sonde nicht – ein Auftrag mit unbekannter Messart wird abgelehnt, nicht ausgeführt.
• Jeder Auftrag ist signiert. Die Sonde prüft die Signatur des Servers, bevor sie irgendetwas tut. Ein untergeschobener Auftrag wird verworfen.
• Die Sonde prüft die Sperrliste selbst. Sie verlässt sich nicht darauf, dass der Server sauber gefiltert hat – interne Adressen lehnt sie unabhängig davon ab.
• Eigene Obergrenzen auf der Sonde: Zahl der Aufträge und Zahl der Pakete je Zeitfenster. Sie greifen, auch wenn der Server mehr schickt.
• Jederzeit abschaltbar, je Gerät im Dashboard und zusätzlich lokal am Agenten.

Was nicht passiert: keine Portscans über Bereiche, keine grossen Nutzlasten, keine Verbindungen zu fremden Diensten ausser den genannten Messarten. Port erreichbar läuft ausschliesslich gegen nachgewiesen eigene Ziele des auftraggebenden Kontos.

Die Karte #

Unter Sonden steht eine Weltkarte des Messnetzes. Ein Punkt je Land, gezeichnet aus dem Land, das die Sonde beim Messen selbst gemeldet hat.

Genauer wird sie bewusst nicht. Es gibt keine GeoIP-Datenbank dahinter – die wäre eine Fremdabhängigkeit, sie wäre ungenau, und sie würde aus einer groben Angabe eine scheinbar genaue machen. Es sind die Server anderer Leute; das Land genügt.

Sonden ohne bekanntes Land verschwinden nicht, sondern werden unter der Karte gezählt. Eine Karte, die stillschweigend die Hälfte weglässt, wäre schlimmer als keine.

Verbindungsbögen erscheinen nur, wenn beide Enden bekannt sind – also wenn das Ziel selbst ein NODE64-Gerät ist. Bei einer beliebigen fremden Adresse weiss der Server nicht, wo sie steht, und soll es auch nicht wissen.

Was ein Knoten leistet #

Auf der Seite eines Knotens stehen neun Merkmale, alle gemessen: ob er ICMP selbst kann, ob er Wege verfolgt, ob er beide Adressfamilien bedient, wie viele Messarten er wirklich geliefert hat, seine Antwortquote, seine längste Lücke, ob er mit den anderen einig ist, ob seine Adresse fest ist und ob sein Standort bekannt ist.

Keine Note. Aus neun Merkmalen eine Zahl zu rechnen hiesse, sie zu gewichten, und dafür gäbe es keine Grundlage ausser einer Meinung. Es steht eine Zählung da – und was sich nicht beurteilen lässt, steht als offen und nicht als Mangel.

Jedes Merkmal trägt seinen Beleg. „Erfüllt" ohne Zahl daneben ist eine Behauptung; „214 von 214 Läufen mit Laufzeit" lässt sich nachprüfen und widerlegen.

Bis zum 22.08.2026 standen hier Abzeichen – tausend Messungen, ein Jahr dabei, jede Stunde des Tages einmal gemessen. Sie zählten, was jemand gesammelt hat. Was zählt, ist, ob ein Knoten seinen Dienst tut.

Woher die Bestandteile kommen #

• Kartengeometrie: Natural Earth, gemeinfrei. In grober Auflösung (110 m), vereinfacht und gerundet – rund 65 KB, selbst ausgeliefert. Kartenkacheln von einem fremden Server wären durch die Inhaltssicherheitsrichtlinie ohnehin ausgeschlossen.
• Vorbild: RIPE Atlas hat gezeigt, dass ein freiwilliges Messnetz trägt. NODE64 Sonar ist deutlich kleiner und verfolgt einen engeren Zweck, teilt aber die Grundhaltung: Transparenz über das, was gemessen wird, und Sichtbarkeit für die, die ihre Anschlüsse hergeben.
• ICMP, Traceroute, PMTU sind selbst gebaut, ohne Fremdbibliothek. Der Agent bringt bewusst keine Abhängigkeiten mit.

Zwei Programme, nicht eines mit einem Schalter #

Seit August 2026 liefert NODE64 zwei Programme:

Warum getrennt. Ein Sicherheitsagent, der auch misst, hat ausgehenden Verkehr zu Zielen, die jemand anders bestimmt hat. Wer ihn prüft – und das ist der Sinn eines quelloffenen Agenten –, muss dann den Quelltext lesen, um zu verstehen, warum das harmlos ist. Getrennt lässt sich der Zweck jedes Programms am Netzverkehr ablesen.

Der Sicherheitsagent hält während eines Laufs genau eine Verbindung: zum eigenen Server. Das lässt sich nachmessen, ohne uns zu glauben:

deploy/tools/agent-gegenstellen.sh

Ein Rechner darf beides tragen. Zwei Einheiten, zwei Verzeichnisse, zwei Schlüssel – wer das Messnetz anhält, hält die Sicherheitsprüfung nicht mit an.

Eine Sonde ist kein Gerät #

Bis dahin musstest du erst ein Sicherheitsgerät anlegen, um eine Sonde zu bekommen. Wer nur einen Messpunkt aufstellen wollte – einen Raspberry Pi bei einem anderen Anbieter, eine kleine Maschine in einem anderen Land –, musste ihm dafür einen Sicherheitsagenten mitgeben, den er nicht wollte.

Eine Sonde wird jetzt eigenständig angelegt. Sie beschreibt einen Messpunkt: Standort, Anbieter, Adressfamilien, Ruf und ob der Knoten ein Master-Knoten ist. Ob auf demselben Rechner auch ein Sicherheitsagent läuft, ist eine getrennte Entscheidung.

Die Einwilligung liegt in der Handlung. Eine Sonde aufzusetzen ist die Zustimmung; ein zweites Häkchen daneben wäre eine Frage an jemanden, der die Antwort gerade gegeben hat.

Bestandssonden behalten alles. Kennung, Master-Rolle und Ruf ziehen mit um. Ein Ruf baut sich über Monate auf und ist der eigentliche Wert einer Sonde.

Aufsetzen #

cp node64-sonar /usr/local/bin/
cp deploy/node64-sonar-agent.service /etc/systemd/system/
node64-sonar enroll --token <Marke aus dem Dashboard>
systemctl enable --now node64-sonar-agent

Das Programm ist 6,2 MB gross und braucht im Betrieb rund 8 MB Arbeitsspeicher.