Verbindung zu Server mit Cloudfare Tunnel extrem langsam,bei gleichzeitig akiver VPN Verbindung

[Justinh]

Hallo, ich habe gerade eine wie ich sie beschreiben würde recht merkwürdige Situation bei mir.


Ich habe folgendem Aufbau:
1. Ich habe meinen Server der öffentlich im Internet hängt und auf dem mehrere Webserver laufen (oder genauer gesagt Home Assitent, ist aber egal , da es alle Sachen betritt die auf dem Server laufen) läuft
2. Dieser Server hat eine dauerhafte Tunnel Verbindung zu Cloudfare, damit ich die Dienste die auf ihm laufen per https ereichen kann.
3.Dieser Server hält zusätzlich zu dem Cloudfare Tunel eine dauerhafte VPN Vebindung zu meiner Fritzbox die hier bei mir steht(der Server steht in einem anderen Netztwerk). Ich habe in den IP Routes auf dem Server festgelegt , dass über dass VPN zu mir nur Adressen im Bereich von 192.168.188.0/24 geleitet werden(in diesem Bereich vergibt meine Fritzbox DHCP Addressen). Alle anderen Dinge also auch die Verbindung zu Cloudfare wird über die Default Route geleitet(die Default Route ist eine unbeschränkte/ohne Ausgangsregeln
Internetverbindung nach draußen).

Dieses ganze System funktioniert soweit auch stabil und einwandfrei, zumindestens solange ich nicht in meinem Heimatnetztwerk bin, zudem der Server eine dauerhafte VPN Verbidung hält.


Erstmal, ich kann aus meinem Heimatnetztwerk die öffentliche IP Adesse aufrufen und komme auch einwandfrei und ohne Probleme auf die Webserver drauf die dort laufen.
Die Probleme fangen erst an wenn ich versuche über die Domain zuzugreifen mit der ich immer auf den Server auch von außen zugreife und diese Domain führt über den Cloudfare Tunnel.
Teilweise konnte es vor, dass ich gar keine Verbindung herstellen kann und die meiste Zeit ist die Verbindung einfach nur extrem lahm.Beispielsweise brauche ich um die Home Assitent Startseite zu laden (die wirklich nicht groß ist circa 3 min (über ein anderes Netztwerk ist sehe ich sie innerhalb von 1 Sekunde ).

Wichtig dabei ist, dass dieses Problem dauerhaft existiert und dieses Problem wirklich nur auftritt, wenn ich von meinem Heimatnetztwerk versuche eine Verbindung über den Cloudfare Tunnel zu meinem Server aufzubauen.Sobald ich mein Heimatmetztwerk verlasse kann ich sofort und schnell den Server und in diesem Fall Home Assitent ereichen.

Die VPN Verbindung stelle ich via dem VPNC Client unter Linux und mit ikev1 her.

Hat eventuell jemand einen Tipp / irgendeinen Anhaltspunkt woher dieses Verhalten kommt?

 

[blurrrr]

Hi,

so ganz klar ist das Konstrukt irgendwie noch nicht...

Ich habe meinen Server der öffentlich im Internet hängt

Wozu dann überhaupt den Cloudflare-Tunnel?

Dieser Server hat eine dauerhafte Tunnel Verbindung zu Cloudfare, damit ich die Dienste die auf ihm laufen per https ereichen kann.

Dann hängt er ja eigentlich doch nicht selbstständig öffentlich im Netz?

Dieser Server hält zusätzlich zu dem Cloudfare Tunel eine dauerhafte VPN Vebindung zu meiner Fritzbox die hier bei mir steht(der Server steht in einem anderen Netztwerk).

Wohin geht denn die Reise, wenn Du den Server über einen öffentlichen FQDN ansprichst (Linux: traceroute <fqdn> Windows: tracert <fqdn>)? Gehen die Pakete durch den VPN-Tunnel, oder doch - wie vorgesehen - direkt ins Internet zu Cloudflare und dort dann durch den Tunnel?

Irgendwas lokales in Richtung DNS ist nicht zufällig im Einsatz (wäre ggf. noch das Thema Split-DNS). Bei Problemen mit den Zugriffen... schon mal die Browser-Console geöffnet und dort mal unter Netzwerk nachgeschaut? Dort sollte sich dann auch einsehen lassen, was von wo bezogen wird.

 

[Justinh]

Wohin geht denn die Reise, wenn Du den Server über einen öffentlichen FQDN ansprichst (Linux: traceroute <fqdn> Windows: tracert <fqdn>)? Gehen die Pakete durch den VPN-Tunnel, oder doch - wie vorgesehen - direkt ins Internet zu Cloudflare und dort dann durch den Tunnel?

Hallo,
Ich habe mir mal die Traceroute angesehen und ich seh jetzt erstmal nicht aufälliges.Dass Packet scheint direckt durch Internet zu Claudfare zu gehen und von dort zum Server.

  1     3 ms     3 ms     5 ms  fritz.box [öffentliche IP meines Heimrouters]
  2    56 ms     8 ms    10 ms  2003:0:8704:5800::1
  3   197 ms   164 ms   179 ms  2003:3c0:1600:800a::1
  4   166 ms   166 ms   166 ms  2003:3c0:1600:800a::2
  5     *        *        *     Zeitüberschreitung der Anforderung.
  6   166 ms   168 ms   166 ms  ae-1.a08.asbnva02.us.bb.gin.ntt.net [2001:418:0:2000::2bb]
  7   171 ms   167 ms   167 ms  2001:418:0:5000::a9b
  8     *        *      169 ms  2400:cb00:352:3::(Claudfare Netztwerk)
  9   167 ms   167 ms   166 ms  [IPV& Adresse des Tunels der zum Server führt]

Ich habe dass ganze dann auch nochmal mit einem Traceert aus einem anderen Netztwerk heraus verglichen und sehe auch dort keine Aufälligkeiten:

  1    12 ms    12 ms     6 ms  2a00:20:7019:527::c8
  2     *        *        *     Zeitüberschreitung der Anforderung.
  3     *        *        *     Zeitüberschreitung der Anforderung.
  4    59 ms    31 ms    28 ms  2a00:0:0:bd0a::6
  5     *       70 ms    41 ms  2a00:0:0:bd09::3
  6     *        *        *     Zeitüberschreitung der Anforderung.
  7    59 ms    41 ms    35 ms  2a00:0:0:bd08::1
  8     *        *        *     Zeitüberschreitung der Anforderung.
  9     *        *        *     Zeitüberschreitung der Anforderung.
 10    84 ms    43 ms    45 ms  2400:cb00:48:2::c629:f012[Cloudfare Netztwerk]
 11    87 ms    46 ms    38 ms  2400:cb00:48:3::[Cloudfare Netztwerk]
 12    41 ms    40 ms    35 ms  [IPV6 Adresse des Tunnels , der zum Server führt]

Bei Problemen mit den Zugriffen... schon mal die Browser-Console geöffnet und dort mal unter Netzwerk nachgeschaut? Dort sollte sich dann auch einsehen lassen, was von wo bezogen wird.

Ich warte gerade auf eine Nicht Ereichbarkeit. Sobald ich wieder in die Lage komme, dass der Server nicht ereichbar ist (aus meinem Heimnetztwerk) werde ich mir dass ganze mal ansehen.

Hi,

so ganz klar ist das Konstrukt irgendwie noch nicht...

Wozu dann überhaupt den Cloudflare-Tunnel?

Dann hängt er ja eigentlich doch nicht selbstständig öffentlich im Netz?

Doch der Server hängt selbstständig im Netzt aber der Cloudfare Tunnel sorgt für 2 Dinge:
1. Ich spare mir Portfreigaben auf dem Server, da der Tunnel ja von innen aufgebaut wird und nicht von außen wie es ja z.b der Fall wäre, wenn ich von außen direkt auf die IP des Servers gehen würde(per Domain Name oder Direkt)=> weniger offene Ports=> Sicherheitsaspekt
2. Damit ich die Dienste auf dem Server per Https ereichen kann, dass würde zwar auch anderes gehen, indem ich einfach bei meiner Domain als Weiterleitung die IP des Servers hinterlege und auf dem Server dann die entsprechenden Zertikate hinterlege, dass ganze aber nur mit Portfreigaben.
Zugegeben derzeit läuft nur Home Assitent ohne Portfreigabe, die anderen Dineste auf dem Server laufen zwar auch über den Cloudfare Tunnel aber ich leite auf dem Server mittels Reverse Proxy an die öffentliche Ipv4 des Servers mit entsprechendem Port weiter(alles erledigt vom Cloudfared Plugin in HomeAssitent).
Dafür muss ich noch eine Lösung finden, ich denke dass beste hier wären einfach mehrere Cloudfare Tunnels. Aber dass ist ja hier auch nicht dass Thema.

 

[blurrrr]

Zugegeben derzeit läuft nur Home Assitent ohne Portfreigabe, die anderen Dineste auf dem Server laufen zwar auch über den Cloudfare Tunnel aber ich leite auf dem Server mittels Reverse Proxy an die öffentliche Ipv4 des Servers mit entsprechendem Port weiter(alles erledigt vom Cloudfared Plugin in HomeAssitent).

Sorry, das was Du da schreibst, macht für mich so gar keinen Sinn, also vor allem dieser Teil:

ich leite auf dem Server mittels Reverse Proxy an die öffentliche Ipv4 des Servers mit entsprechendem Port weiter

Wenn wir von "Server" reden, sprechen wir doch über diesen "einen" auf dem u.a. auch HA läuft, oder nicht? Da läuft dann "auch" noch ein Reverse-Proxy? Falls ja - warum wird dann vom Server über den dortigen Reverse-Proxy "nochmal" weitergeleitet an irgendeine weitere öffentliche IP? Irgendwie steh ich da ein bisschen auf dem Schlauch... Für mich sah das Konstrukt bisher wie folgt aus:

Client <--Internet--> Cloudflare <--Tunnel--> HA

Vielleicht machen wir das mal anders: Was für ein Server ist es denn und was läuft darauf? Blech? VPS? Alle Dienste einfach lokal installiert, oder via Docker, oder ggf. virtualisiert? Wenn virtualisiert wird: Irgendwelche internen Netze oder zusätzliche öffentlichen IP-Adressen für die verschiedenen VMs?

Wichtig dabei ist, dass dieses Problem dauerhaft existiert und dieses Problem wirklich nur auftritt, wenn ich von meinem Heimatnetztwerk versuche eine Verbindung über den Cloudfare Tunnel zu meinem Server aufzubauen.

Ich warte gerade auf eine Nicht Ereichbarkeit. Sobald ich wieder in die Lage komme, dass der Server nicht ereichbar ist (aus meinem Heimnetztwerk) werde ich mir dass ganze mal ansehen.

Das hatte sich eigentlich so gelesen, als wäre es ein Dauerzustand... Also geht es manchmal auch einfach und das Problem ist dann doch eher temporärer Natur?

 

[Justinh]

Mini Glossar:
1. Problemnetzt = Mein Heimatnetzt zu dem die dauerhafte VPN Verbindung vom System steht.
2. System = Dass System / die Instanz bei meinem Cloudanbieter auf der alles läuft , was ich hier beschreibe.

Das hatte sich eigentlich so gelesen, als wäre es ein Dauerzustand... Also geht es manchmal auch einfach und das Problem ist dann doch eher temporärer Natur?

Hallo,
entschuldige bitte die sehr späte Antwort. Ich war mir nicht sehr sicher, ob das Problem eventuell nur temporär ist.

Deshalb habe ich mir jetzt 1 1/2 Wochen Statistiken erstellt, um einzugrenzen, wie “schlimm” das Problem für mich wirklich ist. Am Ende bin ich auf Folgendes gekommen:
Durchschnittliche Ladezeit andere Netze: 10 Sekunden (Minimum: 8,9 Sekunden, Maximum: 15 Sekunden)
Durchschnittliche Ladezeit Problemnetz: 3 Minuten (Minimum: 50 Sekunden, Maximum: 9 Minuten)
Im Problemnetz war das System insgesamt 15 Mal nicht erreichbar (das könnte man vermutlich als temporär abtun)
In anderen Netzen war das System 1 Mal nicht erreichbar.

Also das Fazit daraus wäre, dass die Erreichbarkeitsprobleme mehr oder weniger temporär sind, aber die Bandbreitenprobleme sind definitiv nicht temporär.

Vielleicht machen wir das mal anders: Was für ein Server ist es denn und was läuft darauf? Blech? VPS? Alle Dienste einfach lokal installiert, oder via Docker, oder ggf. virtualisiert? Wenn virtualisiert wird: Irgendwelche internen Netze oder zusätzliche öffentlichen IP-Adressen für die verschiedenen VMs?

Also auf dem Server laufen mehrere Dienste:

1. Rustdesk (in Docker-Container)
2. Home Assistant Supervisor (das läuft zum Großteil in Docker, aber es gibt auch dort den Home Assistant OS Agent, der direkt läuft (ohne irgendetwas dazwischen wie z.B. Docker))
3. Jellyfin (als Home Assistant Add-On => in Docker-Container)
4. Einen YT-DLP Server (damit ich von meinem Amazon Echo Dot Musik von YouTube Music abspielen kann) => im Docker-Container
5. Portainer => in Docker-Container installiert

Ich habe sehr darauf geachtet, alles, was möglich ist, in Docker zu installieren, aber manches wie der Home Assistant OS Agent muss logischerweise auf dem Host-System an sich laufen. In Home Assistant an sich laufen natürlich jede Menge Integrationen, die ihre Daten senden und empfangen (teilweise auch über VPN an mein Heimnetz), z.B. die Steuerung für meine smarten Steckdosen hier.

Ich denke aber, die hier aufzulisten, würde nichts bringen, da ich Home Assistant als ein großes System betrachte (Plugins sind da natürlich was anderes, aber diese laufen alle in Docker).

Interne Netze habe ich einige in Docker.
1. Dass Standart Docker Netzt und dass Standart Bridge und Standart Host Network( 172.18.0.0/16,172.17.0.0/16,)
2. Home Assitent spannt sein eigenes Docker Netzt auf (172.30.32.0/23)
3. Rustdesk auch(172.20.0.0/16)
4. und der yt-dlp server auch(172.23.0.0/16)
Auf dem Host habe ich m,ir auch mal mittels tcpdump --list-interfaces alles auflisten lassen und da kommt einigen zusammen:

1.enp0s6 [Up, Running, Connected]
2.hassio [Up, Running, Connected]
3.docker0 [Up, Running, Connected]
4.br-948d2e587273 [Up, Running, Connected]
5.br-beb8e45d482f [Up, Running, Connected]
6.vethce3c254 [Up, Running, Connected]
7.vethe669ae5 [Up, Running, Connected]
8.vethb707e36 [Up, Running, Connected]
9.vethd0c186f [Up, Running, Connected]
10.veth2b992ff [Up, Running, Connected]
11.veth404617a [Up, Running, Connected]
12.veth35fd936 [Up, Running, Connected]
13.veth173d582 [Up, Running, Connected]
14.vethe9e855c [Up, Running, Connected]
15.vethc5d60da [Up, Running, Connected]
16.vethe6297be [Up, Running, Connected]
17.tun0 [Up, Running, Connected]
18.veth85f75c4 [Up, Running, Connected]
19.veth7e618c8 [Up, Running, Connected]
20.vethca7d3a3 [Up, Running, Connected]
21.veth296c5c3 [Up, Running, Connected]
22.veth91fffc6 [Up, Running, Connected]
23.veth3b40e5b [Up, Running, Connected]
24.veth5d75b58 [Up, Running, Connected]
25.veth7249196 [Up, Running, Connected]
26.any (Pseudo-device that captures on all interfaces) [Up, Running]
27.lo [Up, Running, Loopback]
28.br-b8a68bb2f456 [Up, Disconnected]
29.bluetooth-monitor (Bluetooth Linux Monitor) [Wireless]
30.nflog (Linux netfilter log (NFLOG) interface) [none]
31.nfqueue (Linux netfilter queue (NFQUEUE) interface) [none]
32.dbus-system (D-Bus system bus) [none]
33.dbus-session (D-Bus session bus) [none]

Ich schätzte mal dass die ganzen veth Netztwerke auch von Docker kommen(auch wenn Docker sie selbst nicht als Netztwerke anzeigt), ich sehe dort keine Aufälligkeiten.

Wenn wir von "Server" reden, sprechen wir doch über diesen "einen" auf dem u.a. auch HA läuft, oder nicht? Da läuft dann "auch" noch ein Reverse-Proxy? Falls ja - warum wird dann vom Server über den dortigen Reverse-Proxy "nochmal" weitergeleitet an irgendeine weitere öffentliche IP? Irgendwie steh ich da ein bisschen auf dem Schlauch... Für mich sah das Konstrukt bisher wie folgt aus:

Client <--Internet--> Cloudflare <--Tunnel--> HA

Auf dem Server laufen noch weitere Dienste (siehe oben in diesem Beitrag).

Ich nutze das Cloudflared-Plugin in Home Assistant. Dieses macht Home Assistant über den Cloudflare-Tunnel ohne Portfreigabe verfügbar und bietet einen internen Reverse-Proxy an. Dieser erstellt bei Cloudflare einen neuen DNS-Eintrag (der dann als Ziel die ID des Tunnels hat, der mich zu meinem System weiterleitet). Der Reverse-Proxy leitet mich dann an die öffentliche IP des Servers mit dem jeweiligen Port weiter. Theoretisch sollte es auch möglich sein, über einen Cloudflare-Tunnel mehrere Dienste freizugeben, ohne dass ich die Ports auf dem Server öffnen muss (als IP für die Weiterleitung könnte auch 127.0.0.1 gehen). Das Cloudflared-Plugin in Home Assistant kann aber mit localhost oder 127.0.0.1 nichts anfangen.

Warum das so ist, kann ich dir auch nicht erklären, aber dadurch kommt das Weiterleiten auf die öffentliche IP des Servers zustande. Das Ganze ist auch nur eine Lösung, weil ich zu faul war, den Cloudflare-Tunnel selbst zu konfigurieren, aber es funktioniert (hat aber auch weniger Sicherheit, da ich Ports auf dem Server offen lassen muss).

Ich glaube nicht, dass das gesamte Problem etwas mit dem Cloudflare-Tunnel zu tun hat (da es ja in anderen Netzen absolut einwandfrei und ohne Probleme funktioniert), aber es bleiben auch nicht mehr viele andere Fehlerquellen möglich, wenn ich bedenke, dass sobald ich am Cloudflare-Tunnel vorbei direkt auf die öffentliche IP des Servers gehe, alle Probleme im Problemnetz beseitigt sind.

 

[blurrrr]

Durchschnittliche Ladezeit andere Netze: 10 Sekunden (Minimum: 8,9 Sekunden, Maximum: 15 Sekunden)

Was genau das bedeutet, hängt wohl davon ab, wie Du gemessen hast - würdest Du das ggf. auch noch erläutern? (Kleine Datei durch die Gegend kopiert, einfach nur Website aufgerufen, etc.)

Ich nutze das Cloudflared-Plugin in Home Assistant. Dieses macht Home Assistant über den Cloudflare-Tunnel ohne Portfreigabe verfügbar und bietet einen internen Reverse-Proxy an.

Soweit klar, die Frage zielte eher darauf ab, ob auf dem Server selbst "zusätzlich" noch ein Reverse-Proxy läuft.

1. Ich habe meinen Server der öffentlich im Internet hängt und auf dem mehrere Webserver laufen (oder genauer gesagt Home Assitent, ist aber egal , da es alle Sachen betritt die auf dem Server laufen) läuft
2. Dieser Server hat eine dauerhafte Tunnel Verbindung zu Cloudfare, damit ich die Dienste die auf ihm laufen per https ereichen kann.
3.Dieser Server hält zusätzlich zu dem Cloudfare Tunel eine dauerhafte VPN Vebindung zu meiner Fritzbox die hier bei mir steht

Was das angeht... Cloudflare ist ja nu nur ein "Addon" für "HomeAssistant". Das sollte theoretisch den restlichen Server nicht betreffen, ebenso wenig den ausgehenden Traffic und noch viel weniger Traffic, welcher am Tunnel vorbei geht (direkte Ansprache des Servers von extern, oder eben auch durch den VPN-Tunnel). Die Cloudflare-Geschichte sollte daher lediglich "eingehend" (über den HA-FQDN) greifen.

In Home Assistant an sich laufen natürlich jede Menge Integrationen, die ihre Daten senden und empfangen (teilweise auch über VPN an mein Heimnetz), z.B. die Steuerung für meine smarten Steckdosen hier.

Na dann funktioniert die Kommunikation zwischen Deinem Heimnetz und dem Server ja erstmal und ich kann mir auch nicht vorstellen, dass Du....

Durchschnittliche Ladezeit Problemnetz: 3 Minuten (Minimum: 50 Sekunden, Maximum: 9 Minuten)

.... 3 Minuten warten musst, bis die smarte Steckdose bei Dir Zuhause angeht, welche Du kurz zuvor auf dem Server via HA geschaltet hast, oder?

Das mit den Interfaces ist übrigens schon ok, solange es da keine Überschneidungen mit real existierenden Netzen gibt, wobei sich die Docker-Netze (meine ich) per default im Bereich 172.16.0.0/12 bewegen, während die ganzen SOHO-Router dann eher via 192.168.0.0/16 unterwegs sind, von daher sollte das dann schon passen.

Theoretisch sollte es auch möglich sein, über einen Cloudflare-Tunnel mehrere Dienste freizugeben

Klar, das dürfte dann eingehend am FQDN festgemacht sein, nach hinten raus dann halt via IP/Port (ggf. ebenfalls FQDN).

Das Cloudflared-Plugin in Home Assistant kann aber mit localhost oder 127.0.0.1 nichts anfangen.
Warum das so ist, kann ich dir auch nicht erklären, aber dadurch kommt das Weiterleiten auf die öffentliche IP des Servers zustande.

Das ist eigentlich recht einfach erklärt: Die "Addons" sind i.d.R. "eigenständige" Container. Jeder Container hat i.d.R. seine eigene interne IP. Hast Du nun 2 Container (HA + Cloudflare), könnte das z.B. so aussehen: "HA: 172.17.1.10"+"Cloudflare: 172.17.1.20". Wenn Cloudflare nun "localhost" oder "127.0.0.1" anspricht, versucht er mit sich selbst zu sprechen (anstatt mit dem HA-Container) und ist somit natürlich auf dem völlig falschen Dampfer. Wenn HA die Ports exposed (also über den Host erreichbar macht), wäre es also korrekter, wenn es etwas in Richtung <Server-IP>:<exposed HA-Port> wäre. Da passiert dann quasi das gleiche wie bei Dir Zuhause - es ist ein internes virtuelles Netz mit eigenen IPs und was von extern erreichbar sein soll, wird quasi über eine Portweiterleitung draussen veröffentlicht und ist somit über die Server-IP erreichbar.

Router -> Portweiterleitung -> Host im LAN
Server -> Portweiterleitung -> Container im virtuellen Docker-Netz

Zumindestens habe ich mir das so grob erklärt, bin allerdings auch kein Docker-Spezi...

wenn ich bedenke, dass sobald ich am Cloudflare-Tunnel vorbei direkt auf die öffentliche IP des Servers gehe

Naja, das spricht ja schon dafür, dass dahingehend irgendwas nicht stimmt. Schaut man sich die Traceroutes aus #3 an, sieht man auch sehr schön, wie beim "2." die Latenzen soweit alle im Rahmen bleiben, beim 1. allerdings schnellen die Latenzen schon ziemlich früh sehr hoch:

1 3 ms 3 ms 5 ms fritz.box [öffentliche IP meines Heimrouters]
2 56 ms 8 ms 10 ms 2003:0:8704:5800::1
3 197 ms 164 ms 179 ms 2003:3c0:1600:800a::1
4 166 ms 166 ms 166 ms 2003:3c0:1600:800a::2

Und da haben die Pakete noch nichtmals das Telekom-Netz verlassen... Das Theater geht also quasi schon direkt bei Dir vor der Haustür los. Anderswo scheint es nicht so zu sein:

1 12 ms 12 ms 6 ms 2a00:20:7019:527::c8
2 * * * Zeitüberschreitung der Anforderung.
3 * * * Zeitüberschreitung der Anforderung.
4 59 ms 31 ms 28 ms 2a00:0:0:bd0a::6

Dennoch... solche hohen Latenzen direkt vor der Haustür sind definitiv nicht normal. Ist das denn "dauerhaft" so mit den hohen Latenzen? Vielleicht machst Du erstmal ein Ticket bei der Telekom auf und wenn das geklärt ist, kann man sich auch um anderweitige Probleme kümmern. Nebst dem: Traceroute auch mal ruhig zu verschiedenen Zielen ausführen.

Auch wenn es nur 10 Minuten sind, welche man sich rückwirkend anschauen kann (inkl. Latenzen und Paketverlust), vielleicht hilft das hier ja ein wenig beim Troubleshooting: https://www.pingplotter.com/download/