End2End und Atlas-Probes

Kennen Sie das Projekt „RIPE Atlas“ (https://atlas.ripe.net/) Es ist ein verteiltes Monitoring des Internet mit kleinen Probes (Hardware oder Software). Eine Erklärung und Gegenüberstellung hilft auch beim Verständnis der Thematik eines End2End-Monitorings.

Herausforderung

Das Internet ist ein riesiger Verbund vieler Rechner, Router und Provider bei dem es keine zentrale Firma gibt, die den Betrieb sicherstellt. Es gibt die Root-DNS-Server, welche für die Namensauflösung zuständig sind und die fünf Vergabestellen (RIPE NCC, ARIN, APNIC; LACNIC, AfriNIX) für IP-Adressen über lokale Provider. Darüber steht das ICANN als „Non-Profit-Organization“. Im Prinzip arbeiten alle Institutionen und Provider gemeinsam an dem Ziel, das Internet als dezentrales Netzwerk funktionstüchtig zu halten. Provider überwachen ihr eigenes Netzwerk, die Verbindung zu den zahlenden Kunden und ihre Peerings aber stellen diese Informationen in der Regel nicht öffentlich bereit.

Es weiß also niemand, wie gut es dem Internet gerade geht und ob bestimmt Teilnetzwerk nicht oder nur schlecht erreichbar sein oder DNS-Blockaden z.B. auf Zensur schließen lassen.

Wie funktioniert Atlas?

Das RIPE NCC in Amsterdam hat daher ATLAS gestartet, welches eine Plattform zum Austausch von Konfigurationsdaten und Messergebnissen ist, die durch Probes ausgelesen und geliefert werden. Das RIPE NCC stellt dabei nur das Portal und das Backend bereit, während jeder eine Probes einrichten und betreiben kann. Anfang 2024 waren über 12.000 Probes aktiv, die ca. 15.000 Messungen/Sek durchgeführt und an die Atlas-Server des RIPE gesendet haben.

Der Betreiber einer Probe muss sich erst ein kostenfreies Konto beim RIPE NCC anlegen und kann dann die Software für eine selbst betriebene Probe kostenfrei herunterladen und installieren. Alternativ gibt es auch eine fertige Hardware mit Ethernet und Stromversorgung. Das RIPE NCC benötigt aber Sponsoren für den Betrieb und die Hardware. Daher habe ich eine Probe als Software einfach auf einer VM gestartet. Die überwacht damit durch regelmäßige Aufrufe gegen vom RIPE definierten Gegenstellen die Verfügbarkeit von meinem Netzwerk. Je mehr Probe-Systeme ihre Daten an das RIPE melde, desto weniger weiße Flecken gibt es auf der Landkarte. Eine Probe führt nur selbst Tests aus aber lauscht nicht auf lokalen Verkehr und ist auch nicht selbst erreichbar. Im Bereich Paderborn sind am 5. Feb 2024 folgende Probes gelistet


Quelle: https://atlas.ripe.net/coverage/

Darunter fallen natürlich "Freifunk"-Probes und VegaSystems als lokaler ISP aber auch einige scheinbar "privat" betriebene Probes

VegaSystems        https://atlas.ripe.net/probes/21416 (Seit 2014) "tl-mr3020"
VegaSystems Elsen: https://atlas.ripe.net/probes/23970 (Seit 2016) "tl-mr3020"
FF-U-Probe https://atlas.ripe.net/probes/12583 (seit 2015) "tl-mr3020"
FF-V-Probe  nchFF-V-Probe         https://atlas.ripe.net/probes/12712 (Seit 2021) "tl-mr3020"

Die vier Probes basieren anscheinend alle auf dem TPLink TL-MR-3020", einem kleinen Taschenrouter für unter 25€, der vermutlich mit OpenWRT  (https://openwrt.org/toh/tp-link/tl-mr3020) und darauf installierter Atlas-Probe läuft. Diese Gerte wurden vom RIPE damals als "Hardware Version 3" verteilt.

Atlas Credits

Durch die selbst gehostete Probe "verdiene" ich als Betreiber als Provider entsprechende "Credits", mit denen ich selbst Erreichbarkeits- und Latenzzeit-Messungen von beliebigen Probes zu anderen Gegenstellen über PING, TRACEROUTE, DNS, TLS, NTP und mit Einschränkungen auch HTTP konfigurieren kann.

Für eine Firma kann es daher sehr interessant sein eine Atlas-Probe zu betreiben und damit nicht nur die Erreichbarkeit der Gegenstellen vom eigenen Netzwerk zu prüfen, sondern mit den verdienten Credits auch andere Probes zu verwenden, um z.B. die eigenen Server von von extern zu überwachen.

Vielleicht ist das auch der Grund, warum die ein oder andere Firma selbst schon eine Atlas-Probe betreibt. Unter https://atlas.ripe.net/probes/public können Sie nach Namen aber auch insbesondere nach ASN suchen, z.B. ob ihr Provider schon eine Probe betreibt. Wenn ich nach dem Netzwerk von Microsoft (AS8075) suche, dann finde ich 36 Atlas-Probes mit 532 Userdefinierte Messungen (UDM). Im AS60294 (Deutsche Glasfaser) gibt es 72 Probes, von denen aber nur 48 verbunden sind.

 Mit den passenden Credits können Sie als Firma damit ohne weitere Aktivitäten z.B. die Erreichbarkeit von Azure Amsterdam zu ihren Servern oder Services messen. Das ist insbesondere für die Firmen interessant, die VMs in Azure betreiben, die auf Dienste bei anderen Cloud-Providern zugreifen.

Grenzen von Ripe Atlas

Viele Probes, viele Zahlen liefern noch keine Antworten, wenn diese nicht in Relation und eine übersichtliche Darstellung gebracht werden. Zudem hören sich 12000 Probes schon viel an aber die meisten werden von Internet Service Providern oder Firmen in ihrem Rechenzentrum betrieben. Ein Atlas-Probe gibt es aber leider nicht als Windows Dienst und schon gar nicht auf einem Client. Der Nutzen für Provider und Hoster ist groß aber für die Firma und deren Anwender nicht, denn einige Dinge kann Atlas nicht, die aus meiner Sicht für eine Endpunkt-Monitoring erforderlich wären.

  • Keine Dauertests mit Zusammenfassung
    Ich schreibe und erkläre immer wieder, dass "einmal Messen pro Minute" nur Mittelwerte über Auslastungen bringe aber keine qualifizierte Aussagen zu VoIP oder Stabilität, wenn Ausfälle weniger Sekunden dauern. Eine Atlas-Probe kann zwar auf wenige Sekunden Wiederholung konfiguriert werden aber die Menge an Daten macht eine Auswertung schwer, da keine Zusammenfassungen (Percenzil, Min, Max, Median) über eine Zeitspanne möglich sind.
  • Keine Konfigurationschecks
    Es wird davon ausgegangen, dass die Atlas-Probe funktioniert aber nicht selbst prüft, ob sie optimal konfiguriert ist. Sie wird ja von einem Profi eingerichtet und läuft nicht auf einem Client.
  • Kein UDP
    Es gibt keine UDP-Test, der ICE/STUN/TURN nachbilden und damit die Erreichbarkeit verschiedener Audio/Video-Dienste prüfen kannn
  • Nicht Windows
    Leider ist eine Atlas-Probe nicht als PowerShell, Windows Applikation oder Windows Dienst verfügbar und kann damit nicht auf einem Anwender-Client mitlaufen.
  • Skalierung
    Anfang 2024 gibt es ca. 12.00 Probes weltweit. Ich denke da würde es schon stören, wenn einige Firmen nun auf all ihren Clients eine Atlas-Probe betreiben würden.
  • Standort
    Eine Atlas-Probe steht in der Regel in einem Rechenzentrum mit 24h Strom, Klima, Ethernet-Netzanbindung. Sie misst damit die Qualität ihrer eigenen Dienste direkt "neben" dem Server oder sogar auf dem Server. Das sagt natürlich nichts über die die Leistung aus, die beim Client ankommt.

Ich hoffe, dass Sie damit den Einsatzbereich und den Nutzen von Atlas besser verstehen. Atlas ist ein leistungsfähiges Werkzeug und jede Firma sollte sich durchaus überlegen, eine entsprechende Probe aufzubauen, um ihr Monitoring zu erweitern und über die verdienten Credits auch andere Probes zum Monitoring der eigenen Dienste einsetzen zu können. Atlas und Rimscout überlappen sich aber nicht, sondern können sich ergänzen.

Atlas Probe betreiben

Wenn Sie nun auf den Geschmack gekommen sind und eine Atlas-Probe selbst betreiben wollen, dann brauchen Sie aktuell ein Linux-System (Debiam oder CentOS). Das kann eine VM sein aber auch ein Raspberry Nano oder die OpenWRT-Basis kann eine Atlas-Probe betreiben. Es ist aktuell kein "Windows EXE/MSI" mit Maus und auch kein vorgefertigtes Paket als VM, ISO oder RPM-Paket. Nur für Docker haben andere Autoren ein Pakete geschnürt. Die Installation ist klassisch ein "GET/Compile/Build/Deploy"-Prozess, der aber gut beschrieben ist.

Ich habe die Atlas-Probe einfach auf meinem Squid (Debian) mitlaufen lassen, auf dem ca. 400 MB addiert wurden. Ich nutze auf meinem Debian 12 Buster das Programm "SU", um mich zum Root zu machen. Andere Derivate nutzen vielleicht SUDO vor dem Aufruf.:

# Mache mich erst mal rum Chef. Das "-" hinter SU ist wichtig
su -

# Installation der erforderlichen Module und Werkzeuge zum kompilieren
apt update && apt install git tar fakeroot libssl-dev libcap2-bin autoconf automake libtool build-essential

# RIPE Atlas Repository kopieren
git clone --recursive https://github.com/RIPE-NCC/ripe-atlas-software-probe.git

# deb-Datei im aktuellen Arbeitsverzeichnis zusammenbauen lassen 
./ripe-atlas-software-probe/build-config/debian/bin/make-deb

# Installation des DEB-Pakets. Eventuell muessen Sie die Versionsnummer anpassen
dpkg -i atlasswprobe-5080-1.deb

Bei der Installation der Probe wird ein Schlüsselpaar im Verzeichnis /var/atlas-probe/etc/probe_key.pub generiert.

# Auslesen des PublicKey. Der komplette Inhalt ist erforderliche
cat /var/atlas-probe/etc/probe_key.pub

Diesen öffentlichen Schlüssel muss ich auf https://atlas.ripe.net/apply/swprobe/ eintragen. Damit kann sich die Probe gegenüber dem Atlas-Netzwerk eindeutig authentifizieren und die Verbindung ist zudem verschlüsselt. Nach der Anmeldung sollte ich meine Probe auf https://atlas.ripe.net/probes/mine finden und auch im Posteingang eine Willkommensmail erhalten haben.


https://atlas.ripe.net/probes/mine

Über die ID kann ich weitere Einstellungen vornehmen, z.B. Benachrichtigungen an meine beim RIPE hinterlegte Mailadresse, die genauer Angabe des Orts und später auch ein Wechsel des Public Key, die Übergabe an ein andere RIPE-Konto oder die Löschung steuern. Sie können auch dein Limit für die maximal durch die Probe verwendbare Bandbreite setzen. Auf "https://atlas.ripe.net/messages/" finden Sie die Nachrichten zu den Probes und Veränderungen.

Weitere Hinweise finden Sie auf:

Damit kann die Probe erst mal ein paar Tage "laufen".

Wenn Sie nicht startet, dann kontrolliere Sie die lokalen Logfiles auf "/var/atlas-probe/status". In meinem Fall hat sich die Probe dran gestört, dass ich die der SSH-Konfiguration die Anmeldung als ROOT erlaubt hatte.

Install the RIPE Atlas Software Probe in Debian/Raspbian/Ubuntu in 15 minutes (English)
https://www.youtube.com/watch?v=8uvzE6bhks4

Install the RIPE Atlas Software Probe in CentOS 7/8 Binary (RPM) in 5 minutes (English)
https://www.youtube.com/watch?v=SNecvbNYi20

RIPE NCC : RIPE Atlas
https://www.youtube.com/playlist?list=PLDWsJmznqM9FxRW14Edq14Sl4Zm896_B6

Kommunikation

Natürlich habe ich der Probe mit Wireshark auf die Finger geschaut und ohne weitere Konfiguration macht er nur ein paar HTTPS-Requests und DNS-Anfragen

Bei den DNS-Anfragen ist etwas komisch, dass er nicht die konfigurierten DNS-Server sondern eigene DNS-Server fragt. Damit dies funktioniert, muss die Firewall natürlich 53/TCP ins Internet erlauben.

Name Typ Server Antwort Bemerkung

U1726009.He3b0c44298fc1c14.sos.atlas.ripe.net

AAAA

Default

 
ame: nl-ams-as3333-3.anchors.atlas.ripe.net
Address: 2001:67c:2e8:3::c100:a4
Aliases: U1726009.He3b0c44298fc1c14.sos.atlas.ripe.net
ping.ripe.net

Interessant, dass mein IPv4-DNS-Server bei einer Antwort eine IPv6-Adresse liefert, obwohl es im LAN kein IPvv6-Deployment gibt. Die Anfrage wird ca. alle 180 Sekunden wiederholte

ctr-hel09.atlas.ripe.net

A

Default

 
95.216.246.243

 
host.bind
und
id.server

TXT

 193.0.14.129
192.36.148.17
192.5.5.241
199.7.83.42
192.168.102.204
202.12.27.33
170.247.170.2
192.33.4.12
199.7.91.13
192.112.36.4
192.203.230.10
198.97.190.53
192.58.128.30

Unterschiedliche Namen der DNS-Server

Anscheinend misst und prüft die Atlas-Probe damit die Erreichbarkeit von Root-Servern über den Hostnamen "host.bind", der als TXT-Record den echten Namen des DNS-Servers liefert.

<ihreProbeID>.atlas.ripe.net.62fda848ccd104d1

A

Default

Der Namen ist nicht auflösbar

 

tOPoLogy4.DYndnS.aTlaS.riPE.nET

A

Default

31.31.217.1

 

Es kann durchaus noch weitere DNS-Abfragen geben, die nicht während meiner Analyse passiert sind. Das ist aber nicht alles, denn neben TCP gibt es auch noch ein paar ICMP-Pakete, mit denen ein Traceroute gemacht wird.

Wenn Sie ihre Probe "öffentlich" machen, dann können natürlich auch andere Nutzer Tests zu anderen Gegenstellen konfigurieren.

Das Atlas-Backend stellt auch einige interessant Testgegenstellen bereit. So können Sie z.B. einfach eine variable Datenmenge per HTTP herunterladen

# HTTP-Antwort mit 5 Zeichen 
Invoke-Restmethod http://nl-ams-as3333-3.anchors.atlas.ripe.net/5 | fl

# HTTP-Antwort mit 100 Zeichen 
Invoke-Restmethod http://nl-ams-as3333-3.anchors.atlas.ripe.net/100 | fl

Sicherheit und HTTP

Das könnte aber auch der Grund sein, warum die Probe by Default keine HTTP-Tests macht. Viele Atlas-Probes in Firmen werden vermutlich nicht in einem komplett separierten Subnetz stehen und haben daher "Nachbarn". Nun stellen Sie sich vor, dass ein Angreifer über geschickt definiert HTTP-URls quasi "von Innen" auf ihre Server oder Router zugreifen und einen Exploit ausnutzen kann. Dennoch sollten Sie auch die öffentlichen Informationen im Blick haben. Über die URL  https://atlas.ripe.net/probes/<probeID>/#tab-network verrät die Probe natürlich nicht nur ihre externe IP-Adresse sondern auch ggfls. interne DNS-Server. Gateways etc.

Ich habe auf dieser Seite nicht genau darauf geachtet, die ProbeID unkenntlich zu machen. Sie können über das Atlas-Portal jederzeit nach Probes bei Providern oder an Orten suchen. "Security by Obscurity" ist nie ein guter Ratgeber. Die Probe sollte nicht von extern erreichbar sein und die Webservices beim RIPE dürften entweder genug Bandbreite und Rechenleistung haben oder DoS/DDoS-Filter nutzen.

API Abfragen

Nun sammeln ja die verschiedenen Probes überall Werte ein aber als Administrator möglich ich natürlich nicht täglich per Browser auf der Atlas-Webseite nach Diensten schauen. Dazu gibt es aber eine Atlas-API, über die ich die Abfragen automatisieren kann.

Einen API-Token brauchen Sie nur, wenn Sie Änderungen schreiben möchten. Zum Lesen von öffentlichen Werten reicht der anonyme Zugriff.

InformatInformationen über eine Probe bekommen Sie einfach über eine REST-API. Die Daten genau einer bekannten Probe bekommen wir über die ProbeID.

Invoke-RestMethod https://atlas.ripe.net/api/v2/probes/<ihreProbeID>/

Interessanter sind natürlich Messwerte der eigenen Probe oder auch anderer Probes im Internet. Vielleicht betreibt ja ihr ISP eine Atlas-Probe oder sie finden eine Probe eines anderen Kunden beim gleichen ISP. Am einfachsten suchen Sie die Probe und den Messwert über das Portal, z.B. https://atlas.ripe.net/probes/<ihreProbeID>/#tab-builtins und übernehmen die unten rechts angezeigte URL. Zuerst hole ich mir die Checks:

Invoke-RestMethod "https://atlas.ripe.net/api/v2/measurements/<ihreProbeID>" | ft Description, target,type,result

description        target      type  result
-----------        ------      ----  ------
dns 150.100.6.8    150.100.6.8 dns   https://atlas.ripe.net/api/v2/measurements/<ihreProbeID>/results/

Die "Result"-URL liefert dann die Details zu dem Test. Ich nutze dazu aber die folgende URL, welches mir die Ergebnisse liefert. Hier sind 452 Datensätze vorhanden. Sollten es über 500 sein, dann muss ich die folgenden Daten mit der unter "Next" mitgelieferten URL abrufen.

Das Property "quot; enthält die Ergebnisse und kann recht einfach als Tabelle ausgegeben werden:

(Invoke-(Invoke-RestMethod "https://atlas.ripe.net/api/v2/measurements/?current_probes=<ihre ProbeID>&format=json").results `
|  status,description,query_argument

Hier nur ein Anfang:

Je nach Probe-Type bekommen Sie weitere Werte und über die Parameter sind weitere Filter möglich, z.B. hier auf DNS-Checks

(Invoke-RestMethod "https://atlas.ripe.net/api/v2/measurements/?current_probes=1007491&type=dns&format=json").results `
| ft type, status,description,query_argument

type target                 timeout status                       description
---- ------                 ------- ------                       -----------
dns  f.in-addr-servers.arpa 5000    @{name=Ongoing; id=2; when=} Query f.in-addr-servers.arpa for hostname.bind over I…
dns  f.in-addr-servers.arpa 5000    @{name=Ongoing; id=2; when=} Query f.in-addr-servers.arpa for in-addr.arpa over UD…
dns  f.in-addr-servers.arpa 5000    @{name=Ongoing; id=2; when=} Query f.in-addr-servers.arpa for in-addr.arpa over TC…
dns  f.in-addr-servers.arpa 5000    @{name=Ongoing; id=2; when=} Query f.in-addr-servers.arpa for version.bind over IP…

Leider habe ich noch keinen Weg gefunden, den Zeitpunkt der letzten Prüfung zu ermitteln oder über Filter nur die aktuellen Werte zu erhalten. Ich hatte gedacht, dass ich schnell mal die Werte in PRTG o.ä. überführen kann. Damit bleibt einzig der Status als Indikator übrig.


Quelle: REST API Reference : Measurements https://atlas.ripe.net/docs/apis/rest-api-reference/#measurements

Die Werte könnten wir aber schon z.B. durch PRTG abfrage abfragen und ins eigene Monitoring übernehmen lassen.

Bei meiner Probe sind aktuell keine Fehler zu sehen aber ich habe andere Probes gesucht. Aber selbst eine Probe, die schon über 1h Down ist, liefert immer noch den gleichen Status.

Der Status der Tests erscheint mir daher nicht sonderlich hilfreich.

Wenn Sie aber zu einer Probe die URL "https://atlas.ripe.net/probes/<IhreProbeID>#tab-builtins" aufrufen, dann sehen Sie nicht nur die Bilder sondern unten Rechts auch eine URL

Diese URL erlaubt ihnen den Download der Zahlenreihen zu einem Messpunkt einer Probe samt Filterung nach Zeit. Dazu muss ich mir natürlich erst einmal die "Measurements" holen. In meinem Fall:

$measurements=invoke-restMethod "https://atlas.ripe.net/api/v2/probes/1007491/measurements"

count : 453
next : https://atlas.ripe.net/api/v2/probes/1007491/measurements?page=2
previous :
results : {@{id=1014622; type=Measurement; measurement=https://atlas.ripe.net/api/v2/measurements/1014622/},
@{id=1040113; type=Measurement; measurement=https://atlas.ripe.net/api/v2/measurements/1040113/}, @{id=1040120;
type=Measurement; measurement=https://atlas.ripe.net/api/v2/measurements/1040120/}, @{id=1040122;
type=Measurement; measurement=https://atlas.ripe.net/api/v2/measurements/1040122/}…}

Als Ergebnis bekomme ich aber nur die ID des Measurements und eine URL aber keine weiteren Details. Über die URL kann ich mit dann Die Details dazu holen

Invoke-RestMethod "https://atlas.ripe.net/api/v2/measurements/1014622/" `
| fl description,type,protocol,query_argument,Status,result


description    : weekly resolve www.google.com
type           : dns
protocol       : UDP
query_argument : www.google.com.
status         : @{id=2; name=Ongoing; when=}
result         : https://atlas.ripe.net/api/v2/measurements/1014622/results/

Mit der URL aus dem Feld "result" kann ich mir dann die Daten holen. Allerdings sollte ich dabei auf jeden Fall mit Filtern arbeiten, denn der "{pk}"-Wert (MeasurementID) beschreibt einen Check, der von bis zu 1024 Probes genutzt werden kann.

Create a RIPE Atlas ping measurement using either the website or the API.
You may use up to 1,024 probes.
Quelle: https://atlas.ripe.net/docs/apis/rest-api-manual/measurements/status-checks.html#quick-start

Insbesondere die "Default Checks" sind entsprechend umfangreich. Ich sollte daher immer noch meine ProbeID mit als Filter vorgeben. Für einen einfache Test tut es die MeasurementID = 1, die ein Ping zum Default Gateway ist.

PS C:\> Invoke-RestMethod https://atlas.ripe.net/api/v2/measurements/1/latest/?probe_ids=1007491

dst_name         : 192.168.100.5
dst_addr         : 192.168.100.5
ttl              : 64
sent             : 3
rcvd             : 3
dup              : 0
min              : 0,323
avg              : 0,4143333333
max              : 0,501
result           : {@{rtt=0,501}, @{rtt=0,419}, @{rtt=0,323}}
msm_id           : 1
timestamp        : 1707142867
size             : 40
from             : 217.91.247.140
msm_name         : Ping
type             : ping
fw               : 5080
src_addr         : 192.168.102.204
proto            : UDP
af               : 4
prb_id           : 1007491
stored_timestamp : 1707143030

Eine dritte Variante sind Statuschecks, die sich auf ein Measurement beziehen. Denken Sie daran, dass ein Measurement eine Messung auf eine konfigurierte Gegenstelle ist, die aber von mehreren Probes ausgeführt werden kann. Es ist daher keine einzelne Messung sondern eine Gruppe von mehreren Messungen, bei denen jede Messung einen eigenen Status haben kann.

# Status abfragen (Incinga/Nagio)
Invoke-RestMethod https://atlas.ripe.net/api/v2/measurements/<pk>/status-check?permitted_total_alerts=1

All diese Daten sind natürlich auch für die Integration in ein eigenes Monitoring interessant.

Ich bin noch am experimentieren, wie ich welche Werte von RIPE ATLAS ich z.B. in PRTG übernehmen kann. Eine lokale PRTG-Probe kann viel mehr als eine Atlas-Probe und die von Paessler im Internet verteilten Cloud-Probes können auch von extern messen. Aber es gibt natürlich viel mehr Atlas-Probes und wenn der eigene ISP eine entsprechende Probe hat, dann können diese Daten schon eine Anreicherung darstellen.

Weitere Links