vielleicht mag mir jemand bei meinem denkfehler helfen:
ich möchte das Clients an einem Router die sich mit einem bestimmten Server verbinden wollen ein anderes IF nehmen. Ziel ist bei bestimmten Servern den Verkehr nicht erst über eines der Gateway zu leiten, sondern direkt ab dem Uplink auszuleiten.
48 ip rule list
50 mkdir /etc/iproute2
51 vi /etc/iproute2/rt_tables
# ein Eintrag fb hineingeschrieben
54 ping -c1 openfreiburg.de
56 ip rule add to 178.254.39.111 table fb
63 ip route add default via 2001:XXXXXX::1 dev 6in4-henet table fb
64 ip route flush cache
wie bekomme ich nun die ip rule so das die für clients gilt,
oder sollte ich das lieber ganz anders machen?
sidenote:
das 6in4-henet ist ein Tunnel vom he net Tunnelbroker (und zumindest ping -I 6in4-henet funktioniert prächtig)
# gemäss der he.net Anleitung für openWRT
10 opkg update
11 opkg install 6in4
12 uci set network.henet=interface
13 uci set network.henet.proto=6in4
14 uci set network.henet.peeraddr=216.66.XXXXX
15 uci set network.henet.ip6addr='2001:XXXXX:2/64'
16 uci set network.henet.ip6prefix='2001:XXXXXX/64'
17 uci set network.henet.tunnelid=XXXXXX
18 uci set network.henet.username=fuzzle
19 uci set network.henet.password='XXXXXXXXXXX'
20 uci commit network
21 uci set firewall.@zone[1].network='wan henet'
22 uci commit firewall
23 /etc/init.d/network restart
könntest du meine Frage beantworten oder qualifiziert begründen warum man das nicht für 10-20 IPs machen sollte? So ist halt nur ne Meinung : und da seh ich nicht warum ich das nicht ausprobieren sollte - und dafür hilft die kurzantwort rein garnicht - tschuldige
@Adorfer : war mir nicht klar das du das so mißverstehen würdest. Es
geht eben nicht um die Netzinfrastruktur im Hintergrund und dortiger
„echter“ Router, sondern natürlich um die Plasterouter die die einzelnen
Menschen selber betreiben.
nochmal kurz : Wie kann ich eine Anfrage bspw. zu Youtube , eines
Clients der Wlannetz von Freifunk ist. Und dort freudig hinter
irgendeinem bspw. 841er hängt. direkt über dessen Uplink (WAN)
ausleiten.
Anstatt das die Anfrage regulär über fastdmesh-supernode-exitvpn geht.
Ich dachte, wir hätten uns im „Gluon-erklären“-Thread darauf geeinigt, dies Freifunk-Knoten unter Gluon technisch als Layer2-Bridge zu begreifen und eben nicht als Router. (Und diese allenfalls Volkstümlich als „Plasterouter“ zu bezeichnen. Was im Eingangspost nicht so stand.)
@fuzzle Das Problem liegt primär darin, dass dein Client nicht mal darüber nachdenkt über deinen Knoten zu routen, da er ihn nicht als Gateway kennt. folglich ist er im Layer2 unterwegs und sieht ihn nur als Sprungbrett/Access Point zum eigentlich Gateway/Supernode der auch als Gateway am Client eingestellt ist.
Folglich wird das mit dem Lokal ausleiten eher schwierig.
@Sheogorath … au ja, ich war so fixiert auf den plasterouter … die clinets schicken natürlich all ihren traffic an das dhcp.releaste gateway … blöd
bzw. eine möglichkeit einen gateway mit extrem niedriger ttq auf dem router laufen lassen (sodass sich nur local foo verbindet) … ach, das muss ich mal mit den anderen freiburgern brainstormen
trotzdem danke @adorfer … der link schaut spannend aus, damit könnt man zumindest einiges ab dem gatewayserver rauslassen … was die default-exits verbindungen entlasten würde
Bedenkt aber bitte, dass es leider nciht nur das Störerhaftungs-Szenario gibt, sondern auch das des (Synflood-)Script-Kiddies.
(und was man sonst noch so tun kann).
d.h. das kann bei direkter Ausleitung auch bei besagten Diensten schmerzhaft werden.
Kann man machen, macht aber Routing ziemlich umständlich.
Da bei B.A.T.M.A.N.-adv über den GW Mode eigentlich nur ein DHCP Request Routing stattfindet, wird das Ganze halt irgendwie schon umständlich und hässlich.
Denn hier musst du nun auf dem Router die Defaultroute setzen. Hierzu solltest du natürlich den Status deines defaultrouten Ziels im Auge behalten. Bricht ein GW weg, musst du schließlich switchen oder deine Clients im Regen stehen lassen.
Außerdem verkompliziert es deinen debugging Prozess, da du erst prüfen musst, was dein Ziel ist.
Letzten Endes hast du noch ein weiteres Problem, nämlich der Aufbau des Routings. In deiner ersten Beitrag erwähntest du, dass du gerne YouTube Traffic lokal droppen würdest. Youtube verwendet diverse CDNs um seinen Content an die User zu bringen, das bedeutet du musst entweder in DNS eingreifen und irgendwie nur bestimmte CDN Hosts zulassen, was eine hässliche Lösung ist und zu gefühlt 1 Millionen Probleme führen kann, oder du musst die CDN IPs tracken, was ebenfalls sehr komplex ist.
Ich würde die Idee vorerst auf Eis legen, aber ich bin ja nicht du Außerdem gibt es natürlich für alles eine Lösung, die Frage ist, ob sich der Aufwand lohnt.
Ich würde mich durchaus freuen, wenn es dafür ein Gluon-Package geben würde.
Also
a) Knoten bekommen mehr oder minder manuell eine DHCP-Range verpasst, in der sie „dürfen“
b) Solange die lokale Ausleitung funtkioniert (google-ping… ):
DHCP-Server läuft in Range auf ACK,
Node propagiert sich selbst als Gateway mit niedriger Bandbreite und 30er Hop-Penalty
c) Wenn Ausleitung tot ist: DHCP-Server schaltet in aktiven NAK-Betrieb, um die Clients zu verjagen und nimmt auch das Gateway heraus.
d) Knotenaufsteller definiert, welche Art/Klasse von Webseiten (ASINs) und/oder Portranges direkt ausgeleitet werden soll.
e) In der lokalen Community bekommt niemand Bauchschmerzen wegen der dann mangeldnen Netzneutralität dieses Services.
Warum ich mir das wünsche?
Weil wir z.B. in Geflüchtetenunterkünften 150MBit/s UM-Business-Anschlüsse haben, die sowieso schon auf Firmen/Vereine angemeldet sind. Und Nutzende, die gefühlt 80% des Traffics auf Youtube und Erwachsenenbildungsportale verbraten.
Den Konsum-Traffic könnte man wirklich gut lokal ausleiten, ohne dass es irgendwem weh tut.
Außerdem gibt es natürlich für alles eine Lösung, die Frage ist, ob sich der Aufwand lohnt.