loadbalacing über 2 Uplinks

[frankw]

Hallo,

nachdem ich meine ppp-route in eine separate routing-Tabelle gepackt habe (die andere RT enthält eine statische route als default), würde ich gerne zwischen diesen beiden routingtabellen eine Art load-balancing definieren.

die eine routing-Tabelle (telekom) stellt ca. 1/3 der Gesamtbandbreite zur Verfügung. Bambit die anderen 2/3

nach einigem googlen würde ich es etwa so realisieren:

Code: Alles auswählen

ip route add default scope global \
                     nexthop via $telekom-gateway dev $telekom-iface weight 1 \
                     nexthop via $bambit-gateway dev $bambit-iface weight 2

wäre das soweit richtig? und wäre das ausreichend, oder muss ich in den IPtables noch irgendwas markieren (habe da einige Beispiele gefunden) oder spezielle rules (die aber dann wieder recht statisch wären), diese würden aber auch die angelegten Tabellen nutzen...das Beispiel oben würde das nicht...ich habe aber keins gefunden, welches sich auf die Tabellen bezieht

hier gibt es z.b. Probleme (Beitrag ist aber auch schon sehr alt):
https://unix.stackexchange.com/question ... l-handling

[unitra]

Vermutlich ist auch da auch NAT im Spiel, auch wenn es nicht explizit erwähnt worden ist.. Wie stellt man sicher daß IP Packete die zu einer bereits bestehenden TCP Session dazu gehören, über das "richtige" Gateway rauskommen?
Von der Backbone Seite ist das einfach, es sind unterschiedliche IP Adressen, pro PPP Session. Aber von der Kundenseite aus, also von deiner Seite aus gesehen, ist das nicht so einfach. Bei UDP ist das egal, aber bei TCP?, Vor allem wenn NAT im Spiel ist. Es gibt keine Ende zu Ende Konnektivität, die wird durch das NAT gebrochen.

Vielleicht liege ich falsch, aber die bereits aufgebaute, beispielhafte TCP Session, wird dann von über 2 unterschiedliche IP Adressen aufgebaut, wenn ein load-sharing mit NAT dazwischen ist. Es wäre kein Problem wenn deine beiden Router (PPPoE Sessions) ein gemeinsames öfffentliches IP Netz ins backbone propagieren würden.

[frankw]

NAT ist im Spiel ja,und nat muss sich ja auch merken,welcher rausgehende port zu welcher ip+innerem port gehört damit die Antwort richtig zugeordnet werden kann. Ich dachte für das Loadbalancing gibt es einen ähnlichen Ablauf. Also dass der Kernel schaut,ob er die session schon kennt (source/destination+port) und den entsprechenden uplink nimmt. Er muss sich ja "nur" aktive sessions merken...die abgebauten fliegen wieder raus.

Aus backbone-sicht zählt nur destination/source...

[frankw]

hallo,

habe hier etwas gefunden, was evtl. funktionieren kann:

https://serverfault.com/a/584764

hier wird mittels CONNMARK eine Markierung gesetzt (per zufall), die den Uplink bestimmt

Code: Alles auswählen

iptables -t mangle -A OUTPUT -j MARK --set-mark 10
iptables -t mangle -A OUTPUT -m statistic --mode random --probability 0.25 -j MARK --set-mark 11
iptables -t mangle -A OUTPUT -m statistic --mode random --probability 0.25 -j MARK --set-mark 12
iptables -t mangle -A OUTPUT -m statistic --mode random --probability 0.25 -j MARK --set-mark 13

ein ähnliches Beispiel, aber auch ohne markirung nach Interface (wichtig für ankommenden Traffic) soweit ich das sehe: https://home.regit.org/netfilter-en/lin ... balancing/

ich habe aktuell schon CONNMARK laufen, um den ankommenden Traffic zu markieren, damit die Antwort darauf den gleichen uplink nimmt

Code: Alles auswählen

wan1=ppp0
wan2=ppp8

iptables -A PREROUTING -t mangle -j CONNMARK --restore-mark
iptables -A PREROUTING -t mangle -i $wan1 -j MARK --set-mark 1
iptables -A PREROUTING -t mangle -i $wan2 -j MARK --set-mark 2
iptables -A PREROUTING -t mangle -j CONNMARK --save-mark

ip rule add fwmark 1 table telekom
ip rule add fwmark 2 table bambit

da ich nur 2 Uplinks habe, müsste ich vermutlich vor dem --save-mark die folgenden 2 Zeilen einfügen:

Code: Alles auswählen

iptables -t mangle -A OUTPUT -j MARK --set-mark 1
iptables -t mangle -A OUTPUT -m statistic --mode random --probability 0.5 -j MARK --set-mark 2

es darf jedoch eine vorhandene Markierung nicht überschrieben werden, das machen die 2 Zeilen aber scheinbar...also zuerst mark=1 und dann mit einer Wahrscheinlichkeit von 50% wird die 1 durch 2 ersetzt...

wie kann ich den block nur ausführen, wenn das Mark noch nicht gesetzt wurde (Traffic kommt von innen)?

[wanne]

Wenn du NAT machst, kannst du vor den Mark-regeln ein --state ESTABLISHED setzen und dann dafür sorgen, das dein NAT das danach richtig regelt.
Üblicher ist es halt die Source IP und SNAT zu routern. Wichtig ist, dass du trotzdem noch dafür sorgen musst, dass je nach src-IP die richtige Routingentscheidung getroffen wird. (Normalerweise routest du immer nur nach destination.)
Die Lehrbuchwariante (und IMHO auch die beste) macht das so, dass man halt sagt dass man Verbinudngen die von gleicher ip/port kombinationen kommen gleich routet: Dann musst du dir gar keine Verbindungen merken.

Code: Alles auswählen

iptables -t mangle -A PREROUTING -j HMARK --hmark-offset 10 --hmark-tuple sport --hmark-mod 3 --hmark-rnd 0xdeb1a4f0 

Danach routest du für 10 und 11 über das schnelle Inerface und für 12 über das langsame.

Siehe auch: https://fossies.org/linux/iptables/exte ... _HMARK.man

[frankw]

So ganz verstehe ich das Konzept nicht, aber dein established -Ansatz hat mich auf diese idee gebracht:

ich könnte doch bei den 2 neuen regeln das mit reinnehmen:

Code: Alles auswählen

−m conntrack −−ctstate NEW 

also nur neue verbindungen mit dem zufallsmark versehen. Die verbindungen von außen (bzw.die erste Antwort von innen) sind im ersten step zwar noch nicht established (3way handshake) aber afair nicht mehr new

mhm, scheint nicht zu funktionieren, aber ich habe auf der zweiten Seite noch was gefunden:

Code: Alles auswählen

iptables -N MARKING
iptables -A PREROUTING -t mangle -j CONNMARK --restore-mark
iptables -A PREROUTING -t mangle -m mark  --mark 0x0 -j MARKING
 
iptables -A MARKING -t mangle ...

wenn ich das richtig lese, wird alles ohne Markierung in eine neue Chain "verschoben" und dann darin die Markierung ermittelt...somit tastet es die bisherigen marks nicht an...habe leider das statistic-modul noch nicht im kernel und will jetzt ungern neustarten.

habe das jetzt mal so probiert:

Code: Alles auswählen

iptables -A PREROUTING -t mangle -j CONNMARK --restore-mark
#iptables -A PREROUTING -t mangle --match mark --mark 1 -j ACCEPT
iptables -A PREROUTING -t mangle -i $wan1 -j MARK --set-mark 1
#iptables -A PREROUTING -t mangle --match mark --mark 2 -j ACCEPT
iptables -A PREROUTING -t mangle -i $wan2 -j MARK --set-mark 2

iptables -t mangle -N MARKING
iptables -A PREROUTING -t mangle -m mark  --mark 0x0 -j MARKING #without mark move to new chain

#currently statistic is missing
iptables -t mangle -A MARKING -j MARK --set-mark 3
#iptables -t mangle -A MARKING -m statistic --mode random --probability 0.5 -j MARK --set-mark 2

iptables -A PREROUTING -t mangle -j CONNMARK --save-mark

somit wird jedes Packet, was noch keine Markierung hat mit 3 markiert und auf dem zugeordneten uplink rausgeschickt...klappt soweit...die anderen beiden Markierungen bleiben erhalten

jetzt muss ich nur noch das fail_over (wenn ein Uplink ausfält) und das richtige load-balancing umsetzen...
habe nur aktuell noch keine Idee, wie ich das fail_over mit der statistic verbinden kann...bzw. wie LINK[12]_UP definiert ist....condition scheint es im kernel 4.14 und 4.19 auch nicht zu geben...

[frankw]

ich habe das loadbalancing jetzt (mit 2 zusätzlichen marks wegen der prio) umgesetzt und habe mir in Anlehnung an dieses Script ein eigenes gebaut:

http://blog.sfsoft.it/2016/01/19/config ... oppia-wan/

prinzipiell macht es via "ping -I $IF $IP -c 1" eine Prüfung, ob der jeweilige uplink funktioniert (mit 2 Ziel-IPs), dann wird sich der Status gemerkt und wenn beide uplinks funktionieren wird das loadbalacing entsprechend geroutet...sollte einer ausfallen werden die Pakete mit dem jeweiligen Mark auf den anderen Uplink geroutet. Im Gegensatz zu dem verlinkten Script, ändere ich die rules nur, wenn sich was ändert und das Ganze läuft in einer Schleife (mit 15s-sleep am Ende)

bin noch am testen, ob es sauber funktioniert, falls dem so ist, kann ich gerne den code hier posten

btw. nachdem ich mich in snat bisschen eingelesen habe, kann ich es wohl nicht nutzen, da ich keine feste öffentliche IP habe...es sind 2 dynamisch vergebene

[frankw]

so wie es aussieht, wird der Ausfall erkannt und die Marks angepasst (habe telekom jetzt deaktiviert...)

Code: Alles auswählen

^C[17:56] frank@bpi-r2-e:~$ ip rule show
0:	from all lookup local 
8:	from 192.168.0.8 lookup bambit-voip 
10:	from all to 217.79.184.12 lookup bambit 
11:	from all to 8.23.224.120 lookup telekom 
100:	from all fwmark 0x1 lookup bambit 
101:	from all fwmark 0x2 lookup telekom 
500:	from 192.168.10.26 lookup bambit 
501:	from 192.168.0.80 lookup bambit 
10000:	from all fwmark 0x3 lookup bambit 
10001:	from all fwmark 0x4 lookup bambit 
32766:	from all lookup main 
32767:	from all lookup default

jedoch scheinen nicht alle Pakete umgeroutete zu werden

mark 1&2 werden eigentlich nur von außen gesetzt und #11 ist für dyndns

ich vermute, dass es Probleme mit DNS gibt, da die Namensauflösung schon nicht funktioniert

Code: Alles auswählen

ping www.gmx.de
ping: www.gmx.de: Temporärer Fehler bei der Namensauflösung

Code: Alles auswählen

Mar 11 18:04:06 bpi-r2-e kernel: [254359.924645] fwmark 3: IN=lan0 OUT= MAC=08:00:00:00:00:00:50:46:5d:38:5c:96:08:00 SRC=192.168.0.21 DST=192.168.0.10 LEN=71 TOS=0x00 PREC=0x00 TTL=64 ID=61181 DF PROTO=UDP SPT=47881 DPT=53 LEN=51 MARK=0x3 
Mar 11 18:04:06 bpi-r2-e kernel: [254359.928129] fwmark 4: IN=lan0 OUT= MAC=08:00:00:00:00:00:50:46:5d:38:5c:96:08:00 SRC=192.168.0.21 DST=192.168.0.10 LEN=71 TOS=0x00 PREC=0x00 TTL=64 ID=61185 DF PROTO=UDP SPT=50739 DPT=53 LEN=51 MARK=0x4

das mark passt,aber out ist leer weil DST ist mein router...es sind aber scheinbar nur DNS-Anfragen an meinen Router...eine weitere Anfrage wird scheinbar nicht markiert...ich habe einen lokalen dnsmasq als dns-server

aktuell sehen meine Regeln so aus:

Code: Alles auswählen

wan1=ppp8
wan2=ppp0

iptables -A PREROUTING -t mangle -j CONNMARK --restore-mark
#iptables -A PREROUTING -t mangle --match mark --mark 1 -j ACCEPT
iptables -A PREROUTING -t mangle -i $wan1 -j MARK --set-mark 1
#iptables -A PREROUTING -t mangle --match mark --mark 2 -j ACCEPT
iptables -A PREROUTING -t mangle -i $wan2 -j MARK --set-mark 2
#set -x
#try load-balancing
iptables -t mangle -N MARKING
iptables -A PREROUTING -t mangle -m mark  --mark 0x0 -j MARKING #without mark move to new chain

iptables -t mangle -A MARKING -j MARK --set-mark 3 #bambit
iptables -t mangle -A MARKING -m statistic --mode random --probability 0.3 -j MARK --set-mark 4 #telekom
iptables -t mangle -A MARKING -m mark --mark 3 -j LOG --log-prefix "fwmark 3: "
iptables -t mangle -A MARKING -m mark --mark 4 -j LOG --log-prefix "fwmark 4: "
#set +x
iptables -A PREROUTING -t mangle -j CONNMARK --save-mark

fehlt noch irgendeine Ausgabe?

ping auf ip geht auch nicht von lokal...scheinbar werden lokale pakete nicht markiert und damit über die default-route der main-tabelle (in meinem Fall telekom) rausgeschickt, was nicht geht. Wie kann ich lokale Pakete markieren? Die sollten doch auch via masquerading markiert werden...aber ich vermute,dass dies zu spät passiert (meine regeln sind ja prerouting und bei lokal wird nicht geroutet).

ich habe gelesen, dass man die marking-rule auf die OUTPUT-Chain anwenden soll und nicht auf PREROUTING um das Problem zu umgehen, hat aber bei mir nicht funktioniert (dann geht trotz funktionierendem Uplink kein ping mehr von lokal), auch wenn ich eine pseudo-default-route in die main-table reinnehme (und die andere davor lösche) und komplett auf der nat-table statt mangle arbeite. Bei letzterem funktioniert das load-balancing scheinbar nicht mehr...ich gehe dann immer auf der default-route raus.

[frankw]

Niemand eine idee?

[wanne]

Ich würde mal die Variante von mir verscuehn. Das ist halt ein Einzieler statt deinen 10. Das ist deutlich weniger Fehleranfällig.
Daneben kannst du mal mit traceroute versuchen, wo was schief geht.

[frankw]

Das problem ist,dass lokaler traffic nicht über die prerouting-chain geht. Traffic, der durchgeht, funktioniert problemlos. Mit traceroute komme ich nicht weiter...ich müsste sehen,mit welchem maek es zu welchem interface raus rausgeht

Wenn ich die output-chain nehme,habe ich andere phämonene...ich vermute dass folgendes passiert:

- interne packete werden richtung default-route geroutet (da nicht markiert)
- nat greift und ersetzt die interne ip durch die öffentliche ip des interfaces der default-route
- evtl findet ein tagging statt...sehe es aber nicht in der log
-packet geht evtl. Zum anderen interface raus,aber mit der alten ip-adresse,somit greift das reverse-path-filtering des isp

[wanne]

Wenn durchgehende Traffic wirklich raus geht: Das ist immer ein bisschen das Problem mit Linux, der nimmt interfaces wie es ihm passt.
Du kannst an dein NAT entweder dein Interface (als -o) dranhängen oder halt explizit nur eine route setzen. Vor allem: nach ppp8 und ppp0 willst du unterschiedliche Subnetze haben.
Linux-Routing kommt per default gar nicht damit zurecht, dass das gleiche Subnetz mehrfach verwendet wrid. (z.B. 192.168.1/24 auf verschiedenen Routern.)
kannst du mal ip r zeigen?
Und zu aller letzt guck, dass dein connect() auf die richtige output Adresse geht.
Und traceroute hilft dir halt schon. Der sagt von welcher Adresse und wo es hängen bleibt (mit Addresse) (Auch wenn du wenig metall hast, hast du ne Menge Adressen.)

Üblicher Feheler geht so:
dein Paket geht nach x.y.z.a Der Linux-Kernel findet die als erstes die Adressse 192.168.2.3 auf eth0. Da schickt er mal los.
Aber dann findet er die route 0/0 via 192.168.1.1 für 192.168.1/24 auf eth1. Also schickt er das Paket von der Adresse 192.168.2.3 über eth1 raus. Und das fällt dann auf die Fresse.

[frankw]

er nimmt die interfaces nicht wie es ihm passt, sondern er findet keine passende route und nimmt daher die default...von daher ist es nachvollziehbar. und da ich auf der Kiste selbst das NAT mache (es sind also 2 interfaces mit je einer öffentlichen IP vorhanden), ist in der OUTPUT-table bereits die öffentliche IP gesetzt, somit kann das acket nicht ohne weiteres zu dem anderen Interface routen. und ich vertehe den Ansatz mit dem traceroute nicht, da der erste host (=access-router des ISP) entweder nicht antwortet (default) oder das Paket wegen der falschen source-Adresse verwirft

Code: Alles auswählen

[19:37] frank@bpi-r2-e:~$ ip r
default dev ppp8 scope link 
10.0.3.0/24 dev lxcbr0 proto kernel scope link src 10.0.3.1 
10.0.8.0/24 via 10.0.8.2 dev tun0 
10.0.8.2 dev tun0 proto kernel scope link src 10.0.8.1 
185.53.40.x dev ppp8 proto kernel scope link src 185.53.42.x 
192.168.0.0/24 dev lan0 proto kernel scope link src 192.168.0.10 
192.168.1.0/24 dev lan1.6 proto kernel scope link src 192.168.1.10 linkdown 
192.168.10.0/24 dev ap0 proto kernel scope link src 192.168.10.1 
192.168.11.0/24 dev wlan1 proto kernel scope link src 192.168.11.1 
192.168.50.0/24 dev lan0 scope link 
192.168.178.0/24 dev wan proto kernel scope link src 192.168.178.10 
217.0.118.54 dev ppp0 proto kernel scope link src 93.201.38.x 

Code: Alles auswählen

[19:40] frank@bpi-r2-e:~$ ip a | grep ppp
42: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN group default qlen 3
    link/ppp 
    inet 93.201.38.x peer 217.0.118.54/32 scope global ppp0
43: ppp8: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN group default qlen 3
    link/ppp 
    inet 185.53.42.x peer 185.53.40.1/32 scope global ppp8

[wanne]

Der saubere weg wäre IMHO:

Code: Alles auswählen

ip route del default dev ppp8 scope link 
ip route add default dev ppp8 scope global src 185.53.42.x 

Eventuell auch ein

Code: Alles auswählen

ip route add default dev ppp8 scope global src 185.53.42.x via 185.53.40.1

Aber ich glaube das via braucht es bei ppp nicht und wird dann auch nicht verstanden.

Erfahrungsgemäß tut das aber aus unerfindlichen Gründen nicht immer.
Notfalls noch ein NAT hinterherschicken:

Code: Alles auswählen

iptables --table nat --append POSTROUTING --out-interface ppp8 -j MASQUERADE

[frankw]

Damit biege ich halt die default-route um,mache aber von lokal kein loadbalancing...das wäre für dwn failover-fall mein notnagel (defaultroute auf das noch funktionierende interface setzen) halte ich aber nicht für sauber,da diese dann bis zum nächsten reconnect so bleibt

[wanne]

Von Lokal laod-balancing outgoing ist eher schwierig.
Normalerweise macht man das von Lokal aus über die Anwendung, dass man auf das richtige Interface bindet. Dein dnsmask unterstützt das (wie praktisch alle Programme, die connect() statt bind() machen) aber nicht.
Mit NAT ist es aber relativ gut machbar:

Code: Alles auswählen

ip route add default dev ppp8 table 8 scope global src 185.53.42.x 
ip route add default dev ppp0 table 0 scope global src 93.201.38.x
ip rule add fwmark 0 table 0
ip rule add fwmark 1 table 8
# Alternativ auch dein statefulles marking. Wichtig ist, dass du OUTPUT nimmst.
iptables -t mangle -A OUTPUT -j HMARK --hmark-offset 0 --hmark-tuple sport,dport --hmark-mod 2 --hmark-rnd 0xdeb1a4f0 
iptables --table nat --append POSTROUTING --out-interface ppp8 -j SNAT --to-source 185.53.42.x 
iptables --table nat --append POSTROUTING --out-interface ppp0 -j SNAT --to-source 93.201.38.x

Der Trick ist, dass der dnsmask sich einfach irgend eine (möglicherweise falsche) IP schnappt und das NAT das ganz am Ende beim POSTROUTING, wenn die Entscheidung gefallen ist wieder gerade zieht.

Edit: Hilfreich ist auch https://s3.amazonaws.com/cp-s3/wp-conte ... wchart.jpg

[frankw]

Kann ich die letzten beiden zeilen auch ohne snat nutzen? Ich habe ja keine festen ip's,somit müsste diese regel immer wieder angepasst werden. Die ersten beiden habe ich bereits über ein ip-up-script realisiert. Die nachfolgenden 2 rules habe ich prinzipiell auch schon

Das nachfolgende marking verstehe ich nicht 100% besonders den rnd-teil. In den letzten 3 zeilen steckt scheinbar die magie,wieder neu zu routen

Lokal muss nicht zwingend loadbalancing gemacht werden,aber ich benötige das marking,um es im failover umrouten zu können

[wanne]

Kann ich die letzten beiden zeilen auch ohne snat nutzen?

Ja du solltest auch auch Maquerade nehmen können. Das ist etwas weniger effizient, du hast ja aber gemeint, dass Rechenleistung eher Wurst ist.

Ich habe ja keine festen ip's,somit müsste diese regel immer wieder angepasst werden.

Du brauchst die IP aber halt eh im src (das ist leider wichtig und wird von den meisten tools nicht korrekt gesetzt.) und da kannst du sie nicht ersetzen. Und wenn du sie hast, kannst du sie auch in der IP-Tables-Ruel verwenden. Kannst du ja auch im ip-up-script machen.

Das nachfolgende marking verstehe ich nicht 100% besonders den rnd-teil. In den letzten 3 zeilen steckt scheinbar die magie,wieder neu zu routen

Die verteilt halt je nach Ports auf Mark 0 und 1. Welche Ports du auf welches Interface haust ist Pseudozufällig.
Je nach Seed Legt er andere Portkombinationen auf die eine Route. Aber egal was du angibst halt immer die Hälfte auf die eine und die andere Hälfte auf die andere.
Algorithmus ist leider etwas komplizierter, sodass man das nicht so einfach nachrechnen kann (rnd ist dann die Variable interval):
https://code.woboq.org/linux/linux/incl ... ash.h.html
Ist aber völlig Wurst. Hat den großen Vorteil zu einer echt zufälligen Auswahl, dass du auf nem anderen Rechner das selbe Mapping verwenden kannst oder nach einem reboot die Verbindungen trotzdem weiter laufen, wenn du wieder den selben seed eingibst. Du spielst da halt mehr oder minder den Zufallsgenerator für den Rechner.
Du kannst da angeben was du willst. deb1a4f0 war leet für Debianfo[rum]

[frankw]

Wie würden die beiden letzten Zeilen mit masquerade aussehen? Das Problem ist,dass die Firewall unabhängig vom ip-up-script läuft und ich die snat-zeilen dann zwischendrin löschen und wieder einfügen müsste.

Rechenlast ist nicht egal, habe aber mit dem masqerading-Ansatz bisher keine Performance-Einbußen oder hohe CPU-AUslastung beobachtet

Wenn ich marks 3+4 haben möchte,muss ich die 0 bei hmark-offset auf 3 setzen oder? Die 2 dahinter sagt ja sicher die möglichen marks,oder? wenn es nur den lokalen traffic betrifft ist die Verteilung eigentlich egal...wenn es den gesamten Traffic betrifft strebe ich eine 2:1 Verteilung an ( 25Mbit/s vs 13Mbit/s )

das ganze darf natürlich die evtl. vorhandenen marks nicht ändern (bestehende Verbindungen) wegen dem NAT, also würde ich die letzten 3 Zeilen in der separaten Chain machen, was evtl. auch das löschen vereinfacht

[wanne]

Wenn ich marks 3+4 haben möchte,muss ich die 0 bei hmark-offset auf 3 setzen oder? Die 2 dahinter sagt ja sicher die möglichen marks,oder? wenn es nur den lokalen traffic betrifft ist die Verteilung eigentlich egal...wenn es den gesamten Traffic betrifft strebe ich eine 2:1 Verteilung an ( 25Mbit/s vs 13Mbit/s )

Ja. Klar.
Wenn du das machst, bekommst du 3,4,5 damit kannst du das 2:1 Verhältnis machen.

Code: Alles auswählen

iptables -t mangle -A OUTPUT -j HMARK --hmark-offset 3 --hmark-tuple sport,dport --hmark-mod 3 --hmark-rnd 0xdeb1a4f0 

Einfach den, den du da schon hast:

Code: Alles auswählen

iptables --table nat --append POSTROUTING --out-interface ppp8 -j MASQUERADE
iptables --table nat --append POSTROUTING --out-interface ppp0 -j MASQUERADE

[frankw]

danke dir, werde das mal ausprobieren...dabei bin ich evtl. auf meinen Fehler gestoßen

nachdem die bisherige markierung gelaufen ist habe ich so das Mark gespeichert:

Code: Alles auswählen

iptables -A PREROUTING -t mangle -j CONNMARK --save-mark

wenn ich natürlich was aus der OUTPUT-Chain markiert hatte (lokal), war die Markierung danach weg, weil nur die PREROUTING gespeichert wurde. sehe ich das richtig?

habe jetzt an meine vorhandenen Regeln das hintenran:

Code: Alles auswählen

iptables -t mangle -N MARKING_LOCAL
iptables -t mangle -A OUTPUT -m mark --mark 0x0 -j MARKING_LOCAL #without mark move to new chain
iptables -t mangle -A MARKING_LOCAL -j HMARK --hmark-offset 3 --hmark-tuple sport,dport --hmark-mod 4 --hmark-rnd 0xdeb1a4f0

iptables -t mangle -A MARKING_LOCAL -j CONNMARK --save-mark

also alles was noch nicht markiert ist in der OUTPUT-Chain in die neue MARKING_LOCAL "schieben", darin dann die Änderungen durchführen und am Ende speichern.

danach kommen dann die 2 MASQUERADING-Zeilen von dir

leider funktioniert das trotzdem nicht mit dem lokalen Traffic...er wird aber markiert...ich habe für die Chain massive einträge in der log, wenn ich das log anschalte:

das ist lokaler Traffic von dem Router an meinen Client (die SSH-Verbindung, über die ich aktuell teste)

Code: Alles auswählen

Mar 26 19:14:08 bpi-r2-e kernel: [1163165.096478] fwmark 3 (l): IN= OUT=lan0 SRC=192.168.0.10 DST=192.168.0.21 LEN=320 TOS=0x10 PREC=0x00 TTL=64 ID=15952 DF PROTO=TCP SPT=22 DPT=42282 WINDOW=713 RES=0x00 ACK PSH URGP=0 MARK=0x3 
Mar 26 19:14:08 bpi-r2-e kernel: [1163165.106421] fwmark 3 (l): IN= OUT=lan0 SRC=192.168.0.10 DST=192.168.0.21 LEN=320 TOS=0x10 PREC=0x00 TTL=64 ID=15953 DF PROTO=TCP SPT=22 DPT=42282 WINDOW=713 RES=0x00 ACK PSH URGP=0 MARK=0x3 
Mar 26 19:14:08 bpi-r2-e kernel: [1163165.116510] fwmark 3 (l): IN= OUT=lan0 SRC=192.168.0.10 DST=192.168.0.21 LEN=320 TOS=0x10 PREC=0x00 TTL=64 ID=15954 DF PROTO=TCP SPT=22 DPT=42282 WINDOW=713 RES=0x00 ACK PSH URGP=0 MARK=0x3 
Mar 26 19:14:08 bpi-r2-e kernel: [1163165.126733] fwmark 3 (l): IN= OUT=lan0 SRC=192.168.0.10 DST=192.168.0.21 LEN=320 TOS=0x10 PREC=0x00 TTL=64 ID=15955 DF PROTO=TCP SPT=22 DPT=42282 WINDOW=713 RES=0x00 ACK PSH URGP=0 MARK=0x3 
Mar 26 19:14:08 bpi-r2-e kernel: [1163165.136486] fwmark 3 (l): IN= OUT=lan0 SRC=192.168.0.10 DST=192.168.0.21 LEN=320 TOS=0x10 PREC=0x00 TTL=64 ID=15956 DF PROTO=TCP SPT=22 DPT=42282 WINDOW=713 RES=0x00 ACK PSH URGP=0 MARK=0x3

interessant ist, dass scheinbar jedesmal ein neues mark vergeben wird...obwohl die Verbindung doch bekannt ist (TCP) und ich doch nur unmarkierte Packete in die Chain verschiebe..sollte da vielleicht die lokalen netze ausklammern...

ich habe aber auch traffic, der scheinbar richtig markiert wird

Code: Alles auswählen

Mar 26 19:14:02 bpi-r2-e kernel: [1163159.172762] fwmark 4 (l): IN= OUT=ppp8 SRC=93.201.43.x DST=y.y.y.y LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=54015 DF PROTO=TCP SPT=22 DPT=54631 WINDOW=31248 RES=0x00 ACK URGP=0 MARK=0x4 
Mar 26 19:14:02 bpi-r2-e kernel: [1163159.238274] fwmark 4 (l): IN= OUT=ppp8 SRC=93.201.43.x DST=y.y.y.y LEN=900 TOS=0x00 PREC=0x00 TTL=64 ID=54016 DF PROTO=TCP SPT=22 DPT=54631 WINDOW=31248 RES=0x00 ACK PSH URGP=0 MARK=0x4

mhm, evtl. liegt das an der Prüfmethode:

Code: Alles auswählen

frank@frank-N56VZ:~
[19:29:26]$ ping www.test.de
PING www.test.de (104.40.176.254) 56(84) bytes of data.
^C
--- www.test.de ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5113ms

wenn ich die IP-Adresse bei der RIPE eingebe, wird nichts gefunden...sehr mysteriös für eine deutsche Domain...nehme ich eine andere domain geht der Ping...aufrufen kann ich die webseite der Stiftung Warentest aber....da wird wohl nur der Ping blockiert...warum auch immer die IP in der RIPE nicht eingetragen ist

jedenfalls lasse ich es mal laufen und schaue, ob es irgendwelche Probleme gibt

[frankw]

so wie es aussieht, landen die Packete nicht mehr in der OUTPUT-Chain, wenn die default-route (aktuell bambit,ppp8) wegbricht...und aktuell nutze ich als filter für "externen Verkehr" das ppp-interface

Code: Alles auswählen

iptables -t mangle -N MARKING_LOCAL

iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark
iptables -t mangle -A OUTPUT -o ppp0 -m mark --mark 0x0 -j MARKING_LOCAL #without mark move to new chain
iptables -t mangle -A OUTPUT -o ppp8 -m mark --mark 0x0 -j MARKING_LOCAL #without mark move to new chain
iptables -t mangle -A MARKING_LOCAL -j HMARK --hmark-offset 3 --hmark-tuple sport,dport --hmark-mod 2 --hmark-rnd 0xdeb1a4f0
iptables -t mangle -A MARKING_LOCAL -m mark --mark 3 -j LOG --log-prefix "fwmark 3 (l): "
iptables -t mangle -A MARKING_LOCAL -m mark --mark 4 -j LOG --log-prefix "fwmark 4 (l): "
iptables -t mangle -A MARKING_LOCAL -j CONNMARK --save-mark

iptables --table nat --append POSTROUTING --out-interface ppp8 -j MASQUERADE
iptables --table nat --append POSTROUTING --out-interface ppp0 -j MASQUERADE

die rules werden von meinem Script korrekt umgebogen (3+4 auf den verbleibenden Uplink):

Code: Alles auswählen

# ip rule show
0:	from all lookup local 
8:	from 192.168.0.8 lookup bambit-voip 
10:	from all to 217.79.184.12 lookup bambit 
11:	from all to 8.23.224.120 lookup telekom 
100:	from all fwmark 0x1 lookup bambit 
101:	from all fwmark 0x2 lookup telekom 
500:	from 192.168.10.26 lookup bambit 
501:	from 192.168.0.80 lookup bambit 
10000:	from all fwmark 0x3 lookup telekom 
10001:	from all fwmark 0x4 lookup telekom 
32766:	from all lookup main 
32767:	from all lookup default

was hier jetzt noch in bambit landet sind meine Test-Rechner bzw. der eine Dyndns.

kann ich irgendwie die Pakete trotzdem packen? oder kann ich eine pseudo-default-route (virtuelles Interface o.ä.) anlegen, auf der ich die Pakete dann richtig routen kann?

so ganz sauber läuft es scheinbar nicht...gerade seiten mit captchas weisen öfters die verbindung ab, vermutlich weil die 2.Anfrage dann von einer anderen IP kommt

[wanne]

so ganz sauber läuft es scheinbar nicht...gerade seiten mit captchas weisen öfters die verbindung ab, vermutlich weil die 2.Anfrage dann von einer anderen IP kommt

Willkommen im Cloudflarenet. Das ist zwar kaputt, da kannst du aber nichts machen.

[frankw]

Wie kommst auf cloudflarenet?

Aber ich denke das problem werde ich nicht gelöst bekommen...Bei den captchas (google) dauert es ja ne weile und dann fliegt die zuordnung (auch hmark raus)...tcp ists eh eine neue verbindung,wenn der link angeklickt wird

maximal das failover, wenn per default alles über einen Anschluss läuft, bei ausfall über den anderen und ohne loadbalancing

[wanne]

Wie kommst auf cloudflarenet?

Weil die die Googlecptchas (und auch alles andere) mit IP-Bindung machen.
Google selbst ist es wurst, von welcher IP du kommst. Die reagieren nur auf Cookies und Referer.

Aber ich denke das problem werde ich nicht gelöst bekommen... […] dauert es ja ne weile und dann fliegt die zuordnung (auch hmark raus)

Nein. hmarks sind hashes. Die gelten für immer auch wenn du nach einem Jahrzehnt wieder rebootest, sind die noch stabiel.
Du kannst dstip hashen:

Code: Alles auswählen

iptables -t mangle -A MARKING_LOCAL -j HMARK --hmark-offset 3 --hmark-tuple dst --hmark-mod 4 --hmark-rnd 0xdeb1a4f0

Hast du nicht so ne schöne verteilung wenn gerade viele Verbindungen zum gleichen Server laufen. Sollte im modernen Internet aber nicht mehr so stark stören.
Die Frage ist eher ob das funktioniert, weil cloudflare viele Server hat.
Wie gesagt: Das ist halt kaputt.