End2End-Router
Wer mit Ende zu Ende Tests arbeitet braucht immer eine willige Gegenstelle. Vielen Administratoren ist aber nicht bekannt, dass viele Router nicht nur per "PING" erreichbar sind, sondern auch eine Echo-Server bereitstellen können
UDP/TCP Echo
Das ist bei PING noch relativ einfach aber ICMP ist eben kein UDP oder TCP. Auch Dateiserver (SMB) oder Webserver gibt es in ausreichender Menge, auch wenn die gemessenen Zeiten aufgrund des Overhead natürlich etwas länger sind. Aber schon die RFC 862 vom Mai 1983 definiert ein "ECHO Protocol", welches ganz einfach als Plattform für Tests genutzt werden kann. Sie brauchen nur einen Echo-Server auf der Gegenseite. Meines wissen haben alle Windows Systemen die optional installierbaren "Simple TCP-Services". Selbst mein Windows 10 Client kann diese Funktion aktivieren:
Tun sie dies nicht ohne Schutz, denn ein Angreifer kann so sehr schnell bidirektional Verkehr erzeugen. Zudem is es nicht nur ein ECHO-Server sondern auch noch ein Daytime und Chargen Service
Der Windows Service unterstützt allerdings kein UDP. Das ist auch besser so, denn bei UDP kann die Source-IP nicht gesichert werden. Ein Angreifer könnte dann ein Paket mit gefälschter IP-Adresse an dieses System senden, welches dann die Antwort an den realen Inhaber sendet. Der Angreifer verschleiert so seine Adresse.
Die Simple TCP Services erlauben keine Authentifizierung aber über die Windows Firewall können Sie natürlich die Erreichbarkeit steuern.
Wenn Sie den noch einen ECHO-Server per UDP bereitstellen wollen, dann gibt es natürlich einige Optionen:
-
PowerShell und UDP
Beschreibung zur Programmierung von UDP mit PowerShell und einem UDP-Echo-Sample - EchoTool - Echo client and server
https://GitHub.com/PavelBansky/EchoTool - Tour 4: "udp-echo"
In den meisten Linux-Distributionen ist ein ECHO-Server enthalten und muss im INETD allerdings aktiviert werden
http://www.zotteljedi.de/socket-tipps/tour_04-udp-echo.html - UDP EchoServer in Python
https://svn.python.org/projects/python/trunk/Demo/sockets/udpecho.py
https://gist.GitHub.com/Manouchehri/67b53ecdc767919dddf3ec4ea8098b20#file-reply-to-empty-udp-py
Es sollte also auch kein Problem sein, mal eben schnell einen Raspberry, virtuellen Server o.ä. bereitzustellen. Es muss ja nicht Port 7/UDP oder 7 /TCP sein, um das Auffinden zu erschweren und wer dann nur noch auf eine bestimmte Payload reagiert, reduziert das Risiko weiter
- RFC 862 Echo Protocol
https://datatracker.ietf.org/doc/html/rfc862 - Echo (Netzwerkdienst)
https://de.wikipedia.org/wiki/Echo_(Netzwerkdienst)
Router und Co
Aber vielleicht müssen Sie gar keinen eigenen Service oder Server starten. Die meisten besseren Router lassen sich nicht nur per ICMP-Ping ansprechen, sondern unterstützen auch die ECHO-Funktion, auch wenn Sie in der Regel nicht standardmäßig aktiv ist. Einige Modelle beinhalten sogar die Funktion, selbst UDP-Pakete an eine hinterlegte Gegenstelle zu senden, die Rückantworten zu sammeln und für den Abruf durch ihre Monitoring z.B. per SNMP vorzuhalten.
Hier eine Liste einige Geräte, die als Spiegel dienen oder sogar aktiv messen können.
Die Liste ist nicht repräsentativ. Andere Geräte können vermutlich auch solche Funktionen bereit stellen. Als Lync und VoIP-Admin warte ich eigentlich nur noch darauf, dass auch VoIP-Gateways diese Funktion integriert haben, damit UDP-Tests als Dauertest genutzt werden können.
Leider habe ich nicht zufällig solche "High-End" Geräte im Zugriff, um ein Setup durchzuführen und zu konfigurieren.
Für mein Netzwerk Assessment, wie ich diese auf Cloud Netzwerk Assessment und Network Assessment beschreibe, kommen diese Weg meist nicht zum Einsatz, da hier das Projekt sich auf wenige Tage oder Wochen und die Clients konzentriert. Die Einrichtung auf Routern u.a. passiert dann eher durch das Netzwerkteam als dauerhafte Konfiguration mit entsprechender Planung und Integration in das vorhandene Monitoring-System.
UDP/TCP Echoserver im Internet
Es gibt tatsächlich einige UDP und TCP-Server im Internet, die auf ECHO-Anfragen antworten. Deren Betrieb ist natürlich nie sichergestellt und irgend jemand bezahlt ja auch für die Bandbreite.
Nutzen Sie solche Server bitte nie als "Performance Test", sondern eher zum Messen von Latenzzeiten.
Adresse:Port:Protokoll | Beschreibung |
---|---|
52.43.121.77:10001/UDP 52.43.121.77:9001/TCP |
Quelle: https://www.digi.com/resources/documentation/digidocs/90002258/tasks/t_echo_server.htm |
52.20.16.20:30000/TCP 52.20.16.20:40000/UDP |
http://tcpbin.org/ |
Es gibt sicher noch weitere Server. Sie sehen aber auch, dass die Server gerade nicht auf Port "7" lauschen.
Übrigens können Sie natürlich auch DNS-Server mit einem einfachen UDP/TCP-Paket anfragen und wenn sie immer den gleichen Namen auflösen, der sich dann im Cache befindet, sollte die Last und Verarbeitungszeit des DNS-Servers minimal sein.
Weitere Links
- Network Assessment
- Cloud Netzwerk Assessment
-
End2End-UDP3478
Ein Skype for Business Edge Server kann als Gegenstelle für TURN-Tests genutzt werden -
PRTG
QoS mit UDP-Mirror
PRTG kann UDP-Pakete an eine Gegenstelle senden und erwartet diese wieder zurück - Ende zu Ende Monitoring
- End2End-File
- PRTG QoS mit UDP-Mirror
- End2End-UDP3478
- End2End Mailbox
- Reporting
- DiskTest
- Walkthrough: Creating a
Windows Service Application in
the Component Designer
http://msdn.microsoft.com/en-us/library/aa984464(v=vs.71).aspx - Creating a Basic Windows
Service in C#
http://www.codeproject.com/KB/system/WindowsService.aspx - Creating a Windows Service
in C#
http://www.c-sharpcorner.com/uploadFile/mahesh/window_service11262005045007AM/window_service.aspx - UDP echo server
http://developerweb.net/viewtopic.php?id=5049 - Echo Protocol
http://en.wikipedia.org/wiki/Echo_Protocol - PSPing
http://technet.microsoft.com/en-us/sysinternals/jj729731.aspx