Posts Tagged ‘smokeping’

Montag, 20. April 2020

upc kappt Peering mit Init7 / Fiber7

Link zu diesem Artikel

Ich habe vor einigen Jahren mit OpenVPN ein Site-to-Site VPN zu einem Bekannten in der Agglomeration Bern aufgebaut und betreibe dieses VPN bis heute.

Der Bekannte ist Kunde von upc cablecom (der schnellste und preiswerteste Anbieter in der Agglomerationsgemeinde) mit einem 300 MBit/s Download-Abo, ich als Städter bekanntermassen Kunde von Fiber7 mit (theoretisch) symmetrischen 1 GBit/s.

Letzte Woche (KW16 2020) waren SSH-Verbindungen zu einem Server beim Bekannten auf einmal sehr, sehr hakelig — die Latenz zwischen Tastatureingabe und erscheinen des Zeichens auf dem Bildschirm war sehr hoch. Bestätigt wurde diese durch meine Überwachung der Geschwindigkeit mit speedtest-cli und Aufzeichnung und Visualisierung der Werte mit Cacti:

Der Einbruch am Dienstag-Morgen war offensichtlich.

Eine fiebrige, verbissene Suche begann: War ein Angreifer in das Netzwerk eingedrungen und zog nun Gigabyte-weise an Daten ab? Oder war ein Rechner eines Mitbenutzers von Malware gekapert worden? Oder führte der Mitbenutzer einfach nur tonnenweise Bittorrent-Downloads durch? Oder war eine Netzwerkkomponente ausgetickt und flutete das Netzwerk und den Router mit Paketen? Oder hatte upc cablecom einfach etwas am Netzwerk geschraubt, worauf der Geschwindigkeitseinbruch manchmal nur mit einem Neustart des Modems behoben werden konnte?

Die Nachforschungen brachten nichts zu Tage, aber immerhin lernte ich folgende Netzwerkanalyse-Tools/Features meiner Infrastruktur kennen:

  • Traffic Analysis des EdgeRouters X ER-X, welcher am Kabelmodem hängt
  • iftop Zeigt in Echtzeit an, von und zu welchen IPs ein Server Daten übertragt (Homepage)
  • iptraf-ng (Homepage)

Am Dienstag-Abend ereilte mich ein Geistesblitz: speedtest-cli misst die Geschwindigkeit von einem Server am Agglomerations-Standort zum Ookla Speedtest-Server von Init7 (Server „Init 7 (Winterthur, Switzerland)“ mit ID 3026). Aus Interesse wählte ich einen anderen Server aus der Liste aus, und zwar den Speedtest-Server von Sunrise. Zuerst führte ich einen manuellen Speedtest zu Init7 durch, danach zu Sunrise. Und siehe da, hier lag die Antwort wie auf dem Präsentierteller:

$ ./speedtest-cli --server 28045
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from UPC Schweiz (80.218.X.X)...
Hosted by Sunrise Communication AG (Lausanne) [6X.XX km]: 30.667 ms
Testing download speed........................................
Download: 302.88 Mbit/s
Testing upload speed..................................................
Upload: 42.32 Mbit/s

$ ./speedtest-cli --server 3026
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from UPC Schweiz (80.218.X.X)...
Hosted by Init 7 (Winterthur) [13X.XX km]: 165.956 ms
Testing download speed........................................
Download: 25.82 Mbit/s
Testing upload speed..................................................
Upload: 9.48 Mbit/s

Am selben Abend sendete ich eine Anfrage an Init7 raus, ob und wie sie sich diesen markanten Geschwindigkeits-Unterschied erklären können. Am Morgen hatte ich die Antwort, und wurde auf folgendes Schreiben verwiesen. Diese Meldung war bei mir im Corona-Trubel vollkommen untergegangen.

Fazit: upc cablecom, how dare you?

Nachtrag

smokeping visualisiert die Latenz von DNS-Abfragen aus dem upc cablecom-Netz gegen den DNS-Server von Init7 ebenfalls sehr schön:

Auf Wunsch Thomas‘ (siehe Kommentar unten) noch dieselbe Grafik für Test-Abfragen an einen der DNS-Server der upc cablecom (ns10.cablecom.net) …

… zu Swisscom (dns2.bluewin.ch) …

… und zu Sunrise (cache02.sunrise.ch)

Tags: , , , , , , , , , , , , , , , , ,
Labels: IT, Schweiz

7 Kommentare | neuen Kommentar verfassen

Mittwoch, 24. Februar 2016

Eine interne Smokeping-Installation über Apache Reverse Proxy verfügbar machen

Link zu diesem Artikel

Heute morgen (US Pacific-Zeit) habe ich mir einige Minuten Zeit genommen, um eine Smokeping-Installation auf dem Linux-Server (nennen wir ihn BETA) in meiner Wohnung in Bern über einen Linux-Server im Elternhaus in Neuenegg zugänglich zu machen. Nur der Apache 2.4 Web-Server auf dem Linux-Server im Elternhaus (nennen wir ihn ALPHA) ist öffentlich aus dem Internet zugänglich.

Wenn Smokeping auf einem bestehenden Server bereits installiert, konfiguriert und aufrufbar ist, ist dieses Vorhaben äusserst simpel:

Als erstes laden wir auf ALPHA die benötigten zwei Proxy-Module:

# cd /etc/apache2/mods-enabled
# ln -s ../mods-available/proxy.conf .
# ln -s ../mods-available/proxy_http.conf .

Weiter erstellen wir ebenfalls auf ALPHA einen virtuellen Host mit folgenden Angaben:

<VirtualHost *:80>
	ServerName smokeping-beta.bern.homeip.net
	ServerAdmin info@eMeidi.com
	
	ProxyPass	/	http://10.1.2.3/
	
	<Location />
		AuthName		"Eyes Only"
		AuthType 		Digest
		AuthUserFile		/etc/apache2/auth/users.digest
		AuthDigestProvider	file
		AuthDigestDomain	/
		
		Require			valid-user
	</Location>
</VirtualHost>

Diese Angaben legen wir unter /etc/apache2/sites-available ab und nennen die Datei beispielsweise smokeping-bern. Schlussendlich aktivieren wir diese folgendermassen:

# cd /etc/apache2/sites-enabled
# ln -s ../sites-available/smokeping-bern

Anschliessend starten wir auf ALPHA den Web-Server neu:

# apache2ctl graceful

Damit Smokeping in der Folge sauber mit allen relativen Pfaden funktioniert, aber auch die Bilder (RRDtool-Graphen) angezeigt werden, rufe ich die Web-Site auf einem beliebigen Computer mit Internetverbindung folgendermassen auf:

http://smokeping-beta.bern.homeip.net/smokeping/smokeping.cgi

WICHTIG: Damit nur authentifizierte Personen auf diesen Reverse Proxy zugreifen können, schütze ich den gesamten Virtual Host mit Benutzernamen und Passwort. Dies ist deshalb auch wichtig, weil meine Konfiguration alle Anfragen auf den Virtual Host an den anderen Server weiterleitet — habe ich in anderen Unterverzeichnissen noch andere Applikationen laufen, wären diese ebenfalls über den Reverse Proxy ansprechbar. Das ist nicht schön, aber momentan als Quick & Dirty-Lösung akzeptabel.

Tags: , , , , , ,
Labels: Uncategorized

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 21. Januar 2016

smokeping auf einem Raspberry Pi installieren

Link zu diesem Artikel

Gestern habe ich einen verstaubten Raspberry Pi 1 aus meinem Endlager für obsolete IT-Hardware gerettet und ihn als arpwatch-Überwachungsstation aufgesetzt. Auf dem Gerät läuft folgendes Debian:

Linux raspberrypi 4.1.13+ #826 PREEMPT Fri Nov 13 20:13:22 GMT 2015 armv6l GNU/Linux

Etwas später stiess ich in Vorbereitung auf meinen Wechsel von upc cablecom zu Fiber7 auf den Artikel Fiber7 performance, in welchem Michael Stapelberg aufzeigt, wie sich die Latenz seiner Internetverbindung nach dem Wechsel von Swisscom auf Fiber7 verbessert hat.

Gedacht — getan: So etwas benötige ich natürlich auch, um meinen bevorstehenden Providerwechsel mit harten Fakten zu untermauern — wobei, ehrlich gesagt, ist mir die Latenz nicht so wichtig (bin kein Gamer), sondern viel mehr der vierfache Durchsatz und die symmetrische Down- und Upload-Geschwindigkeit zum selben Preis wie beim Kabelriesen.

Nichtsdestotrotz installierte ich mir also das Softwarepaket smokeping und seine Dependencies, wie das berühmte rrdtool aus dem Hause Oetiker:

# apt-get update
...
# apt-get upgrade
...
# apt-get install smokeping

Es wurde zwar alles nett installiert, doch konnte ich danach noch nicht auf die Web-Oberfläche unter http://localhost/smokeping/smokeping.cgi zugreifen. Unter einem x86-64 Debian war das nach der Installation automatisch möglich.

Zuerst wohl mal den Apache starten, dachte ich mir:

# /etc/init.d/apache2 start

Der Web-Server kam hoch, zeigte unter http://localhost/ die obligate Startseite an, doch unter dem Smokeping-Link kam ich statt der Smokeping-Oberfläche nur einen HTTP 403er zu Gesicht (mangels Screenshot und Text-Kopie mittels Auszug aus dem Apache error.log unter /var/log/apache2/):

...
[Wed Jan 20 22:52:59.338858 2016] [authz_core:error] [pid 2706:tid 3036673072] [client 10.0.1.101:56967] AH01630: client denied by server configuration: /usr/lib/cgi-bin/smokeping.cgi
...

Oookey … da ich smokeping auch noch auf einem „richtigen“ Linux-Server im Elternhaus laufen hatte, kopierte ich kurzerhand dessen VirtualHost-Konfiguration auf den Raspberry Pi (natürlich als Symlink auf conf-available):

# cat /etc/apache2/conf-enabled/smokeping.conf 
ScriptAlias /smokeping/smokeping.cgi /usr/lib/cgi-bin/smokeping.cgi
Alias /smokeping /usr/share/smokeping/www

<Directory "/usr/share/smokeping/www">
    Options FollowSymLinks
</Directory>

<Directory "/usr/lib/cgi-bin/">
    Options FollowSymLinks
    Require all granted
</Directory>

Noch ein …

# apache2ctl graceful

… und der 403er war weg. Das smokeping-GUI wurde aber weiterhin nicht angezeigt, sondern nur der Inhalt des CGI-Scripts im Klartext:

#!/bin/sh

exec /usr/share/smokeping/smokeping.cgi /etc/smokeping/config

Was zur Hölle … ? Doch auch diesem Fehlverhalten schaffte ich nach 15 Minuten googlen, Artikel lesen und pröbeln den Garaus: Ein simples

# a2enmod cgi

Via: Perl Apache : Perl script displayed as plain text

reichte aus, und plötzlich führte Apache das CGI-Script aus. Halleluja!

Tags: , , , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen