Beiträge von mbo77

  • Kann Vermieter Ausbau verweigern?

    Sieht spannend aus - scheint aber für das Nutzererlebnis keinerlei Auswirkung zu haben.

    Spannend ist auch, dass du der Zeitschrift "Connect" ihre Unabhängigkeit absprichst. Weißt du da mehr?

    Da du ebenso implizierst, dass sie falsch testen: Was stimmt mit dem Test und den Ergebnissen nicht?

  • IPv4-Erreichbarkeit via Portfreigabe auf einem VPS

    Hier noch eine knappe Betrachtung bzgl. der Performance.

    Ich habe gegen meinen VDSL-Anschluss mit 40 Mbps Upload getestet. Diese konnte ich auch voll ausreizen.

    Der besagte VPS für 1€/Monat kommt ja mit nur einer vCPU. In Zeiten, wo jedes Smartphone etliche Kerne mitbringt, mag das wenig erscheinen, aber es geht ja auch nur darum, etwas Traffic zu verarbeiten.

    Es gibt zwei Komponenten, die CPU-Zeit benötigen: WireGuard und 6tunnel.

    Wenn der Kernel selbst filtert und weiterleitet, lag das im Grundrauschen des Systems und wurde durch WireGuard überdeckt.

    Im Mittel konnte ich 90% idle am System beobachten. Wenn 6tunnel den Traffic direkt zu einem IPv6-Ziel transportiert hat oder wenn iptables/WireGuard die Pakete verarbeitet hat.

    Selbst im schlechtesten Fall, wenn WireGuard und 6tunnel zu tun hatten, lag das System noch bei mindestens 75% idle.

    WireGuard hat dabei den größten Impact, da der Traffic verschlüsselt wird. 6tunnel bleibt moderat unter 10% Last.

    So ein VPS mit 1 vCPU ist wohl ohne Bedenken für mehrere hundert Mbps gut. Danach müsste man ggf. über ein potenteres VPS nachdenken. ;)

    PS: Speicher ist ohnehin unerheblich. Der verfügbare Speicher von 0,85/1 GB ist nur zu ca. 250 MB genutzt.

  • IPv4-Erreichbarkeit via Portfreigabe auf einem VPS

    Variation ohne WireGuard und 6tunnel

    Im letzten Beispiel zeige ich eine Möglichkeit auf, wie man Freigaben im Heimnetz via IPv4 erreichbar machen kann, wenn die Ziele bereits via IPv6 erreichbar sind.

    Dazu ist dann keine WireGuard-Konfiguration mehr notwendig.

    Ich habe versucht, im bekannten Diagramm die Änderungen so übersichtlich wie möglich einzubauen - gar nicht so trivial.

    IPv6-Konfiguration

    Wesentlich für die Lösung ist, dass unser fabelhaftes NAS über eine öffentliche IPv6-Adresse erreichbar ist.

    Im fiktiven Beispiel wurde durch die FritzBox ein Prefix 2003:e1:2222:3333::/64 für die Teilnehmer festgelegt.

    Das fabelhafte NAS sollte sich entsprechend eine IPv6-Adresse darin vergeben haben. Dies kann man am System ermitteln und ist abhängig vom (Betriebs-)System.

    Portfreigabe im Router

    Unabhängig davon, ob man später die Freigabe per IPv4 oder IPv6 erreichen möchte, muss dieser aber im Router vorhanden sein.

    In der FritzBox geht man dabei genauso vor, wie bei einer IPv4-Freigabe. Es gibt dabei die Option, Freigaben für IPv4, IPv6 oder beides einzurichten.

    Zudem habt ihr die Möglichkeit, den Host-Anteil zu setzen. Dies sollte man sich ansehen, insbesondere Apekte wie EUI-64, Stable-Privacy und sich ändernden Host-Anteilen (Privacy Extensions). Die FritzBox soll sich ändernde Host-Anteile zwar automatisch erkennen, aber da habe ich widersprüchliche Erfahrungen gemacht.

    IPv6-Adresse im (Dyn-)DNS registrieren

    Unser Ziel soll/muss natürlich via Name erreichbar sein.

    Hierbei ist es wichtig zu verstehen, dass nicht mehr die FritzBox die Registrierung übernimmt, denn jedes Endgerät hat ja nun seine eigene öffentliche IPv6-Adresse. Hier gibt es eine Vielzahl von Lösungen, z.B. https://ddclient.net/.

    Unser fabelhaftes NAS, was vielleicht ein Gerät von Synology oder QNAP ist, bietet hier möglicherweise Optionen in der GUI.

    Man hat jetzt verschiedene Möglichkeiten, entsprechende Records anlegen zu lassen.

    Denkbar ist, dass man einen AAAA-Record für nas.meinefabelhaftedomain.de vornimmt.

    Auch denkbar ist, dies logisch weiter zu strukturieren, z.B. via nas.ipv6.meinefabelhaftedomain.de.

    Dies bleibt jedem selbst überlassen.

    Sobald alles vorbereitet ist, kann man vom VPS die Verbindung prüfen:

    Code
    nc -v nas.ipv6.meinefabelhaftedomain.de 80
Connection to nas.ipv6.meinefabelhaftedomain.de (2003:e1:2222:3333:1:2:3:4) 80 port [tcp/http] succeeded!

    6tunnel

    Wie im ersten Beitrag kommt jetzt wieder 6tunnel zum Einsatz, um zwischen IPv4 und IPv6 zu tunneln.

    Dabei müssen wir das Ziel für den Tunnel etwas anpassen:

    Code
    cat /etc/6tunnel/80
TARGET=nas.ipv6.meinefabelhaftedomain.de
PORT=80

cat /etc/6tunnel/443
TARGET=nas.ipv6.meinefabelhaftedomain.de
PORT=443

    Anstatt auf private Adresse via WireGuard zu verbinden, baut 6tunnel nun eine direkte Verbidung zur Freigabe im IPv6-Netz auf.

    Wir testen aus dem weltweiten Netz:

    Code
    nc -v vps.meinefabelhaftedomain.de 80
Connection to vps.meinefabelhaftedomain.de (80.90.100.110) 80 port [tcp/http] succeeded!

    Kontrolle auf dem VPS:

    Code
    sudo netstat -anpW|grep 6tunnel
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      1219/6tunnel
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      1215/6tunnel
tcp        0      0 80.90.100.110:80        110.111.112.113:43390   ESTABLISHED 1235/6tunnel
tcp6       0      0 2a02:247a:2222:3333:1::1:42680 2003:e1:2222:3333:1:2:3:4:80 ESTABLISHED 1235/6tunnel

    Das sieht gut aus. Eingehend wird eine IPv4-Verbindung genutzt, ausgehend zum Ziel dann eine IPv6-Verbindung.

    Epilog ;)

    Und das soll es jetzt erstmal gewesen sein. In beiden Threads sind verschiedene Optionen aufgezeigt, um das Problem der Erreichbarkeit via IPv4 zu lösen.

    Dabei gibt es sogar eine Lösung, wenn der Provider nicht mal IPv6 anbietet und zudem IPv4 mittels CG-NAT realisiert. Wie ich gehört habe, soll es so etwas geben.

    Das hat keinen Anspruch auf Vollständigkeit. Es sind auch Optionen wie ein Reverse-Proxy o.ä. denkbar.

    Aber das darf dann gerne jemand anderes erklären.

  • Empfehlung Router für deutsche Glasfaser

    Bei manchen Providern möchte man den Kunden sehr stark auf das Provider-ONT drängen.

    Ein eigenes Modem (in der Fritzbox) hat den Vorteil, Merkmale zur Leistungsqualität einsehen zu können.

    Da für dich aber die Kosten eine große Rolle zu spielen scheinen, würde ich die Preise vergleichen.

    Ggf auch eine preisgünstige 7530AX, die es gebraucht schon sehr günstig gibt.

    Ansonsten sind die Unterschiede vor allem in der WiFi-Konfiguration zu finden.

    Ich rate aber einfach mal, dass ihr da kein teures Flaggschiff braucht.

  • IPv4-Erreichbarkeit via Portfreigabe auf einem VPS

    Variation mit iptables

    Die oben beschriebene Lösung lässt sich auch direkt im Linux-Kernel lösen. Das hat den Vorteil, dass keine weitere Software gebraucht wird und die Lösung potenziell performanter ist.

    Übersichtszeichnung

    Wie schaut das ganze aus? Ziemlich ähnlich zur 6tunnel-Lösung.

    Anstelle der 6tunnel-Software konfigurieren wir die Paket-Firewall.

    NAT-Tabelle

    Zunächst einmal setzen wir in der NAT-Tabelle ein paar Regeln, welche eingehende Pakete mittels S(ource)NAT und D(estination)NAT zwischen den Systemen entsprechend umbaut:

    Code
    sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.178.110:80
sudo iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination 192.168.178.110:443

    Damit werden eingehende Pakete, die für tcp/80 und tcp/443 für andere Ziele umgebaut, also auf ein neues Ziel ge-DNAT-et.

    Wenn Pakete nun so maskiert zurückkommen, müssen wir das wieder umkehren:

    Code
    sudo iptables -t nat -A POSTROUTING -p tcp --dport 80 -d 192.168.178.110 -j SNAT --to-source 10.99.99.1
sudo iptables -t nat -A POSTROUTING -p tcp --dport 443 -d 192.168.178.110 -j SNAT --to-source 10.99.99.1

    Da die Pakete an das eigentliche Ziel zuvor von der Adresse 10.99.99.1 verschickt wurden, bauen wir die Pakete wieder zurück, SNAT-en sie also wieder zurück für die Quelle.

    Zur Kontrolle werfen wir jetzt einen Blick auf die Tabelle:

    Damit durchlaufen eingehende Pakete die NAT-Tabelle und werden bei Bedarf entsprechend umgebaut.

    FORWARD-Tabelle

    Im ersten Schritt sind die Pakete für ein FORWARDing vorbereitet und manipuliert worden.

    Jetzt gilt es in der FORWARD-Tabelle dafür passende Regeln anzulegen.

    Code
    sudo iptables -A FORWARD -i ens6 -o wg0 -p tcp --syn --dport 80 -m conntrack --ctstate NEW -j ACCEPT
sudo iptables -A FORWARD -i ens6 -o wg0 -p tcp --syn --dport 443 -m conntrack --ctstate NEW -j ACCEPT

    Damit werden neue Weiterleitungen akzeptiert. Damit auch die dazugehörigen Pakete akzeptiert werden, müssen wir diese Pakete in der Tabelle auch zulassen.

    Code
    sudo iptables -A FORWARD -i ens6 -o wg0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A FORWARD -i wg0 -o ens6 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

    Ich hätte die Regeln zwar auch ein wenig zusammenfassen können, aber zum Zwecke der Nachvollziehbarkeit lasse ich sie so.

    Kontrolle und Sicherung der Arbeit

    Damit ist die Arbeit getan, Zeit für eine konkrete Kontrolle aus dem weltweiten Netz:

    Code
    nc -v vps.meinefabelhaftedomain.de 80
Connection to vps.meinefabelhaftedomain.de (80.90.100.110) 80 port [tcp/http] succeeded!

nc -v vps.meinefabelhaftedomain.de 443
Connection to vps.meinefabelhaftedomain.de (80.90.100.110) 443 port [tcp/https] succeeded!

    Das sieht schon mal gut aus.

    Schauen wir auf dem fabelhaften NAS mal nach diesen Verbindungen:

    Code
    sudo netstat -anp|grep 10.99.99
tcp6       0      0 192.168.178.110:80          10.99.99.1:37970        SYN_RECV    -

sudo netstat -anp|grep 10.99.99
tcp6       0      0 192.168.178.110:443         10.99.99.1:52682        SYN_RECV    -

    Wenig überraschend geht die Verbindung nun von 10.99.99.1 aus, also dem System, was im weltweiten Netz die Anfragen via IPv4 entgegennimmt.

    Für die grundlegende WireGuard-Verbindung hatte wir ja schon Regeln angelegt. Nachdem wir nun weitere ergänzt haben, gilt es diese auch zu speichern:

    In meinem Beispiel habe ich die Firewall noch so konfiguriert, dass sie eingehende Verbindungen zum SSH-Port 22 und natürlich udp/52823 für WireGuard akzeptiert.

    Das habe zwecks Anschauung drin gelassen.

    Abschließend

    Zudem bitte folgendes beachten: In der Regel sind die Policies für die Tabellen auf ACCEPT gestellt. Das heißt, unsere ganzen schönen Regeln sind nutzlos, wenn wir das Tor ohnehin weit aufsperren.

    Im Basissetup mit dem Wireguard-Anteil habe ich die Policy für FORWARD daher zunächst auf DROP gestellt, bevor konkrete Regeln bestimmten Traffic wieder zulassen.

    Es gilt bei dem VPS zu beachten, ob der Hoster das bereits mit einer externen Firewall sichert.

    Die muss alle Ports zulassen, mit denen ihr arbeiten wollt. Also eingehend Richtung Port 22, falls ihr SSH wünscht. Aber auch die Ports für WireGuard und auch die weiterzuleitenden Ports.

    Aber nicht irritieren lassen: In der Paket-Firewall des VPS müssen die Ports, die weitergeleitet werden sollen, in der INPUT-Tabelle nicht geöffnet werden. Die Pakete für die Ports 80 und 443 erreichen diese Tabelle nämlich nie, sondern laufen durch NAT->FORWARD->NAT.

    Und das ist ein technischer wesentlicher Unterschied zur 6tunnel-Lösung. Dort wird die eingehende Verbingung von 6tunnel terminiert und eine neue Verbindung zum Ziel aufgebaut. Hier manipulieren wir die Pakete und leiten sie direkt in der Paket-Firewall/TCP-Stack weiter.

  • Zweiter GF-TA am gleichen HüP

    Wie bei einer CuDA oder Koax, wo man die Leitung einfach in Reihe schalten kann, funktioniert das mit Gf nicht.

    Jede Dose müsste daher eine eigene Faser, sprich Anschluss bekommen.

    Wie man bei GPON selbst sehen kann, ist ein optischer Split natürlich möglich.

    Ich kann mir aber nicht vorstellen, dass dies jemand bei Kunden baut.

    Wenn du also flexibel bleiben möchtest, scheint die bestehende Cat-Verkabelung deine Wahl zu sein.

    ONT vom Provider in den Keller und von dort per Netzwerk zum Ziel. Dann ergibt die Gf-Box allerdings wenig Sinn.

    Alternativ verlegst du Gf-Patchkabel vom EG in den Keller.

  • Empfehlung Router für deutsche Glasfaser

    Da werden viele Begriffe genutzt. Aber ONT kristallisiert sich so langsam raus.

    Das ONT terminiert GPON auf der logischen Ebene und wandelt nebenbei auf Kupfer.

    Wobei es bei AON durchaus auch einen ONT geben kann. Da ist die Terminierung auf logische Ebene sehr viel einfacher.

    Wenn es um Kosten geht, ist eine 7530AX eine gute und günstige Option.

  • IPv4-Erreichbarkeit via VPS und VPN (WireGuard)

    Es ist insgesamt dem Umstand geschuldet, dass ein wg-Interface immer eine Adresse halten muss.

    Der ganze Zauber mit 10.99.99.0/24 wird notwendig, weil der VPS nur die öffentliche Adresse trägt und gar keine LAN-Seite besitzt. Genauso gut könnte ich dem wg-Interface auf dem VPS auch die öffentliche Adresse zuweisen.

    Im Grunde könnten wir das Subnetz komplett sparen, aber mindestens als AllowedIP bei den Peers. Im Grunde wollen wir nie diese Ziele ansprechen, sondern eigentlich immer nur die Adresse im Heimnetz.

    Ich habe es aber drin gelassen, weil es so für einige vermutlich verständlicher ist. Und es dient einer rudimentären Kontrolle, ob die Kommunikation überhaupt funktioniert.

    Was ich beim Versuch, dem wg-Interface auf der FB eine Adresse aus dem Subnet 10.99.99.0/24 zu geben, gesehen habe, dass die Kommunikation dahin dann funktioniert. Aber ein ping zu einer Adresse im Heimnetz meldet sich mit der Adresse aus dem Subnet 10.99.99.2/32 zurück und kommt am eigentlichen Ziel gar nicht an.

    Könnte da Proxy ARP dran beteiligt sein?

  • IPv4-Erreichbarkeit via Portfreigabe auf einem VPS

    Einleitung

    Ergänzend zum Beitrag IPv4-Erreichbarkeit via VPS und VPN (WireGuard) möchte ich weitere Möglichkeiten aufzeigen, einzelne Dienste im Heimnetz erreichbar zu machen.

    Übersichtszeichnung

    Auch hier zunächst eine Übersicht, was erreicht werden soll:

    Auf den ersten Blick hat sich nicht viel getan. Es besteht weiterhin eine WireGuard-Verbindung zwischen einem VPS und dem Heimnetzwerk.

    Daher gehe ich hier nicht weiter auf diese Verbindung ein, bitte im anderen Thread nachlesen.

    Der Unterschied ist, dass hier nun eine Möglichkeit besteht, auf bestimmte Ports/Dienste direkt zuzugreifen, also ohne, dass der (mobile) Client Teil des WireGuard-Netzes wird.

    Das kann durchaus gewünscht oder notwendig sein, wenn ich zum Beispiel möchte, dass meine aufwändig und mit viel Liebe gestaltete Webseite von meinem eigenen "Server" ausgeliefert wird. Dafür gäbe es weitere unzählige Optionen, gerade bei externen Hostern. Aber manchmal möchte man das vielleicht nicht nach extern geben. Zum Beispiel seine eigene Nextcloud-Instanz. Da kann es sinnvoll und einfacher sein, wenn diese an einem öffentlichen Endpunkt verfügbar ist.

    6tunnel

    Ich gehe davon aus, dass die eigentlichen Voraussetzungen bereits geschaffen wurden:

    • Die öffentliche IP des VPS ist sinnvoll im DNS registriert
    • Die WireGuard-Verbindung zwischen VPS und Heimnetz funktioniert
    • Firewall des Hosters ist konfiguriert und auch verstanden
    • Wenn konfiguriert, muss die Paket-Firewall des VPS eingehende Verbindungen zum weiterzuleitenden Port akzeptieren

    Es ist dabei unerheblich, wie die WireGuard-Verbindung etabliert ist: mit oder ohne zusätzlichem Server.

    Ich gehe daher jetzt nur auf die Kernkomponente ein, in diesem Beispiel 6tunnel (https://github.com/wojtekka/6tunnel).

    Es ist ein Applikationstunnel. Ziel ist es, dass eingehende Anfragen an den VPS transparent an das eigentliche Ziel im Heimnetz getunnelt werden.

    Dabei kann sich 6tunnel sowohl zu IPv4 als auch IPv6-Adressen verbinden. In einem abgewandelten Beispiel wird klar, warum 6tunnel hier eine gute Lösung ist.

    Zunächst muss 6tunnel installiert werden, unter Debian-basierten Systemen via:

    Code
    sudo apt install 6tunnel

    Danach lässt sich bereits ein einfacher Test machen.

    Auf dem VPS möchte ich eingehend Port 80 an Port 80 meines NAS weiterleiten:

    Code
    sudo 6tunnel 80 192.168.178.110 80
6tunnel: warning: both local and remote addresses are IPv4

sudo netstat -anp|grep 6tunnel
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      12705/6tunnel

    Da es eigentlich um eine Tunnelung zu einem IPv6-Ziel geht, warnt uns 6tunnel, arbeitet aber völlig korrekt.

    Im zweiten Schritt sehen wir, dass 6tunnel brav auf eingehende Verbindungen wartet.

    Testen wir von einem Client im weltweiten Netz:

    Code
    nc -v vps.meinefabelhaftedomain.de 80
Connection to vps.meinefabelhaftedomain.de (80.90.100.110) 80 port [tcp/http] succeeded!

    Wenn wir jetzt wieder via netstat auf dem VPS die Verbindungen prüfen, sehen wir den Erfolg:

    Code
    sudo netstat -anp|grep 6tunnel
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      12705/6tunnel
tcp        0      0 10.99.99.1:55188        192.168.178.110:80      ESTABLISHED 12744/6tunnel
tcp        0      0 80.90.100.110:80        110.111.112.113:59704   ESTABLISHED 12744/6tunnel

    Wir sehen, dass der Client im weltweiten Netz (110.111.112.113) sich mit dem Ports 80 des VPS verbunden hat. Der wiederum baut zum Port 80 des fabehaften NAS eine Verbindung auf und tunnelt den Datenverkehr.

    Damit ist das Ziel bereits erreicht. Man verfährt analog zu anderen Ports, z.B. Port 443.

    Automatischer Start

    Nachteil ist, dass 6tunnel keine fertigen systemd-Units mitbringt. Nach Neustart des Servers sind die Tunnel also wieder verschwunden und müssen manuell gestartet werden.

    Schöner ist es, wenn systemd sich darum kümmert.

    Auf die Schnelle habe ich keine fertigen Beispiele gefunden, daher habe ich ein Beispiel gebastelt.

    Zunächst legen wir ein Verzeichnis an, wo wir die Konfigurationsdateien ablegen:

    Code
    sudo mkdir /etc/6tunnel

    Danach legen wir für jede Weiterleitung eine Datei an:

    Code
    ll /etc/6tunnel/
total 16
drwxr-xr-x  2 root root 4096 Oct 30 15:52 ./
drwxr-xr-x 95 root root 4096 Oct 30 15:43 ../
-rw-r--r--  1 root root   28 Oct 30 15:52 443
-rw-r--r--  1 root root   27 Oct 30 15:50 80

    Wir brauchen nur wenige Informationen:

    Code
    cat /etc/6tunnel/80
TARGET=192.168.178.110
PORT=80

cat /etc/6tunnel/443
TARGET=192.168.178.110
PORT=443

    Wir legen eine Template-Unit an:

    Ich habe eine Abhängigkeit zum WireGuard-Tunnel gesetzt. Aber selbst ohne, dürfte das kein Problem sein.

    Nun aktivieren wir je eine Unit je Freigabe:

    Code
    sudo systemctl enable 6tunnel@80
Created symlink /etc/systemd/system/multi-user.target.wants/6tunnel@80.service → /lib/systemd/system/6tunnel@.service.

sudo systemctl enable 6tunnel@443
Created symlink /etc/systemd/system/multi-user.target.wants/6tunnel@443.service → /lib/systemd/system/6tunnel@.service.

    Nach Neustart sehen wir, dass die Units geladen wurden und 6tunnel seine Arbeit aufgenommen hat.

    Das geht bestimmt noch ausgefeilter, erfüllt aber zunächst seinen Zweck.

    Ausblick

    In weiteren Abwandlungen geht es um die Idee, Ports durch den TCP/IP-Stack mithilfe von iptables weiterzuleiten.

    Ebenso wird es um eine Lösung gehen, wo der VPS sich ohne Hilfe von WireGuard direkt mit dem IPv6-Ziel des Heimnetzes verbindet.

    Dafür gibt es natürlich auch (kostenpflichtige) Lösungen am Markt, wie z.B. https://www.feste-ip.net/dslite-ipv6-po…-informationen/.

    Diese Lösung ist nicht besser oder schlechter und ohne Hilfe eines VPS einrichtbar. Wer Lust und Erfahrung hat, kann ja dazu vielleicht ein kleines Tutorial erstellen.

  • Speedport Smart 4 Plus an UGG/O2 Netz anschließen

    Realer Fall eines Bekannten: Der hatte sein WLAN so generisch benannt, dass der Nachbar die gleiche glorreiche Idee hatte.

    Und an einigen Stellen des Hauses war das andere WLAN mit der identischen SSID einfach stärker und führte daher zu Abbrüchen. Vielleicht hätten die sich beim Passwort absprechen sollen. ;)

    Also, wie schon gesagt, erstmal schauen, was noch so los ist und ob es keine Konflikte bei den SSIDs gibt etc.

    Auch sollten man schauen, wie die Kanäle belegt werden: Statisch oder dynamisch.

    Im Idealfall sollten die Automatik zum besten Ergebnis führen.

  • Kann Vermieter Ausbau verweigern?

    Worauf auch immer du hinaus willst.

    Für den Nutzer ist ist die Kombination von internem Routing und externen Peering ausschlaggebend.

    Und objektiv gesehen macht die Telekom einen guten Job, siehe unabhängige Tests.

    Und jetzt bin ich wirklich aus der Nonsense-Diskussion raus.

  • Kann Vermieter Ausbau verweigern?

    Peering und Routing gehören unzertrennlich zusammen.

    Irgendwie müssen die verschiedenen Netze ja zusammen kommen. Es dürfte eher selten sein, dass man innerhalb eines AS bleibt.

    Und dann bleibe ich lieber bei meinen Anekdoten und unabhängigen Tests.

    Und mehr werde ich dazu auch nicht beitragen.