Ist es möglich einen VPN-client auf einen anderen Supernode zu verschieben?

Guten Tag Kollegen,

Ich bin vom FF-Südpfalz und ich sehe gerade das es einige Cilents in unserem Netz gibt, die ein erhöhtes Traffic aufkommen generieren. Da wir bei Hetzner nur zwei VM-Server CX10 mit jeweils 2TB Traffic gekauft haben, bekommen wir dadurch bald ein Problem mit der Datenmenge auf einem der zwei Supernodes die darauf laufen.

Jetzt ist die Frage, ist es möglich, die Clients mit höherem Traffic-aufkommen manuell einem Supernode zuzuweisen, auf dem wir noch genug Traffic-Volumen frei haben?
Wir haben keinen SSH Zugriff auf den Client, wir müssten dies vom Server aus steuern.

Gruß aus der Pfalz

hi,
nein, du kannst di en neuen vserver zulegen, was sinn macht und die anzahl der nodes auf dem server begrenzen.

Da mangelt es an einer zentralen Management-Instanz. Der „Client“ der Supernode ist ja beispielsweise schon nichtmal mehr das Smartphone, sondern der Router mit dem Uplink.

Wenn du nur eine Problemzone hast, kannst du die MAC des problematischen Client auf Routerebene ausfiltern und nur auf dem bestimmten Gerät mit der Verbindung zur vorgesehenen Supernode zulassen.

Alternativ kannst du nur nach Erreichen des Maximaltraffics den Server totschalten bzw. den Traffic intern auf die Maschine umleiten, die noch freie Kapazitäten zum Backbone hin hat.

Ich könnte ihn kurzzeitig auf einem Supernode in die Blacklist vom fastd eintragen. Dazu muss ich jedoch den fastd neustarten.
Das ist mir etwas zuviel Aufwand für diese Aktion. :frowning:

Ja OK, ich habe mich falsch ausgedrückt. Ich meine natürlich den Knoten den ich verschieben möchte. Unsere Infrastruktur ist noch zu klein, das wird sich jedoch diesen Monat noch nicht ändern.

Die fastd Blacklist ist da schon genau richtig.

Du schließt ja niemandem aus, sondern verlagerst den Node nur auf einen anderen Gateway.

Fastd neustarten ist doch nur ein Befehl.

service fastd restart

Also doch nicht viel Aufwand. Alternativ kannst du den Nodeaufsteller bitten, nur den anderem Gateway zu nutzen.

Mehr dazu hier: Konsole – wiki.freifunk.net

Ein Ansatz wäre, in der Supernode, die als erstes volläuft, den Tunnel zum Backbone abzubauen. Somit könnte die Supernode alle übrigen Aufgaben erledigen und ihren Traffic bei den freien Supernodes abkippen.

Das ist auch eine Idee danke. Wir haben ihn jetzt kurzzeitig in die fastd Blacklist auf einem Server eingetragen und warten jetzt ab was passiert.

Ok, hat ohne manuellen fastd restart funktioniert.
Beim nächsten fastd Handshake wurde der Knoten blockiert woraufhin er sich mit der anderen Supernode verbunden hat.

Ich glaube wir haben da aber was nicht zu Ende gedacht.
Der Knoten ist jetzt zwar auf der anderen Supernode, die Clients haben aber noch die DHCP-Leases, also auch das Gateway vom vorherigen Supernode.
Also haben wir vermutlich nur für Quer-Traffic zwischen den Supernodes gesorgt und der Traffic geht trotzdem noch über den alten Supernode ins FFRL-Backbone.

1 Like

Nja 2TB Traffic ist nicht gerade viel. Könnte ein PowerUser inerhalb weiger Wochen aufbrauchen.
Würde auf einen Root wechseln da hatt man um die 20TB

Das Geld dafür muss ja auch irgendwo herkommen…

Wenn Ihr die Route für das FFRL-Backbone nun über den zweiten Supernode legt, sollte er wieder dorthin zurück gehen und von dort ins Backbone gehen, oder?

Ist zwar netzwerktechnisch sinnarm, aber abrechnungstechnisch brauchbar, weil Hetzner internen Traffic nicht berechnet (AFAIK).

Ich habe dann mal das Betreff angepasst, da ich auch -ohne den kompletten Thread zu lesen- anmerken wollte, dass es nicht möglich ist, einelne clients zu verschieben auf andere Gateways, da die Routingentscheidung Batman getroffen wird und man dort allenfalls global mit Hop-Penalty oder announcter Bandbreite eingreifen kann.
Was dann aber dazu führt, dass dieses Announcment alle betrifft (mindestens alle Clients eines Nodes) und nicht nur einzelne Clients.