Ihr merkt ich bin jetzt völlig verwirrt, weil ich eigentlich denke das Routing nicht so schwer sein kann. Im Moment verbeißen wir uns auf die Table 42. Und so wie ich das sehe verbiegen wir hier nur Sachen um an mein altes Setup IC-VPN anzupassen. Was aber hier irgendwie nicht fruchten will.
Es muss doch möglich sein das:
Bird seine Routen in die Main Table ballert, so das sowohl der Host GW1 als auch die Clients die vom Interface br-ffue aus kommen ins IC-VPN gelangen und auch Anfragen aus dem IC-VPN zurück zum Host und auch zurück zu den Clients mit 10.134.0.0/16 Hostadresse gelangen.
Das Anfragen von Hosts aus 10.134.0.0/16 nicht via das Default Gateway (eth0) des Gateway raus gehen wenn sie nach 0.0.0.0/0 wollen sondern über TUN0 raus.
Du musst Dir verdeutlichen was genau Du da gerade machst, dann wird es einfacher.
Indem Du Dir eine eigene Routing Table generierst, bspw. die Table 42 sorgst Du erstmal lediglich dafür, dass Du ein weiteres default Gateway benutzen kannst.
Mit den IP Rules legst Du Regeln fest, die bestimmen welche Pakete statt über die Main Kernel Table (mit der default route ins Internet, die der Server braucht) über die Tabelle 42 gerouted werden.
Dein Setup wird mittlerweile ziemlich zerblasen sein, durch die Rumtesterei. Mach, wie wusel das bereits empfohlen hatte, mal nen Neubeginn.
Du brauchst lediglich folgende Dinge auf Deinem Server:
ALLE Routen (bis auf die default Route aus der Main Table) konsequent in der Table42
IP Rules für ALLE Schnittstellen des Servers (außer eth0) auf Table42
IP Rules ALLER internen Netze auf die Table42
SNAT Regel für das Interface des Tunnels
Default Gateway aus dem OpenVPN ebenfalls in Table42
Nicht mehr und nicht weniger, dann läuft alles so wie es soll!
Die Main Kernel Table ist für Dich dann vollkommen uninteressant und sorgt lediglich dafür, dass die Tunnel aufgebaut werden können etc.
Danke für eure Geduld mit mir. Falls wir uns mal treffen, gibts nen Bierchen oder ein anderes Getränk.
Ich muss jetzt erst mal meine Hausaufgaben machen. Sprich ich muss erst mal feststellen wo welche Config in meinem System geschrieben steht. Man hat sich damals ja von allen Communitys hier und da Config Code raus kopiert bisschen angepasst und wenns dann funktionierte nicht mehr angeschaut.
Eigentlich müsste ich mir ne weitere Maschine besorgen, den die letzten Tage basteln hat nicht nur freundliche Reaktionen ausgelöst bei den Netz Nutzern.
Ich kann Dir 'ne Bastel-VM geben … Und ich gebe Dir nochmals den Rat, es mit erprobten, zumindest wiederholbaren Konfigurationsmöglichkeiten zu versuchen; WAS dann wie aufgesetzt wird, führt dann im Nachhinein ggf. zum Aha-Effekt, war jedenfalls bei mir so.
Chris schrieb es ja schon, meine Spielerei mit Mullvad auf bgp1 gestern (die mich natürlich erstmal dank Routenübernahme für v4 & v6 von der VM aussperrte – route-nopull vergessen ;)) sollte es auch gezeigt haben: das ist im Grunde kein Hexenwerk. Aber dynamisches Routing in >1 Routingtabelle ist auch nichts für copy&paste aus drölf Wiki-Fragmenten an einem Nachmittag (trust me, so sind gw01/gw04 bei uns entstanden, und da wage ich mich heute nicht mehr ran, bin froh, daß das noch soweit tut wie’s im Übergang muß).
One step at a time. 10.134.10.1 sollte nach wie vor gehen, denn – es sei denn, Du hast die Regeln gelöscht – -i br-ffue markierst Du doch mit 0x1 und 0x1 schickst Du in Tabelle 42. ip rule add to 10.0.0.0/8 pref 10 table 42dürfte also nichts ändern, denn 10.1340.10.1 sollte schon vorher in Tabelle 42 gesucht worden sein … BTW, seit 12:16 habe ich keine ARP-Anfragen mehr nach 10.134/16 auf dem ICVPN bekommen, 10.134.0.0/16 dev br-ffue src 10.134.10.1 scheint nun auch in Tabelle 42 wieder zu stehen?
[quote=„Freifunker, post:41, topic:6672“]
Ihr merkt ich bin jetzt völlig verwirrt, weil ich eigentlich denke das Routing nicht so schwer sein kann. Im Moment verbeißen wir uns auf die Table 42. Und so wie ich das sehe verbiegen wir hier nur Sachen um an mein altes Setup IC-VPN anzupassen. Was aber hier irgendwie nicht fruchten will.[/quote]
… weil Dein Setup bislang auf eine Routingtabelle und statisches Routing ausgelegt ist/war: Von 10.134/16 (aus br-ffue) nach Welt über tun0, Antworten werden zurückgenattet auf Ziel aus 10.134/16. Da reicht eine Routingtabelle, Hostroute auf den VPN-Server via default und 0/1 + 128/1 über’s VPN, fertig ist die Laube (okay, iptables … -o tun0 -j MASQUERADE noch, damit’s funktioniert; für’s Routing an sich ist das nicht nötig ;)).
Jetzt willst Du aber zu n anderen Netzen routen, die aber nur für Dein Netz 10.134/16 erreichbar sind, der Host kann damit nicht viel anfangen. Das Vertrackte ist halt zu sehen, was in welcher Routingtabelle stehen muß und wie es da rein kommt. Ein Vogel macht noch keinen Sommer, wie Du gesehen hast, fehlen in Tabelle 42 einige Einträge aus Tabelle main. Das muß man berücksichtigen, bird lernt nur die Routen der Peers, für die eigenen muß man entweder durch entsprechende Einträge in bird.conf sorgen oder sie beim hoch-/runterfahren der Interfaces entsprechend setzen:
(Das fällt übrigens aus dem besagten puppet-Kram raus.) Man beachte, daß die vom Kernel automatisch in die main-Tabelle aufgenommenen Routen über das Interface für Tabelle 42 ebenfalls erzeugt werden. Das ist einer der Punkte, der bei Dir IMHO für Probleme sorgt: fehlende (lokale) Routen in Tabelle 42.
Insgesamt habe ich eigentlich nur 3 Files die auf meinem Gateway was mit dem Routing machen.
Zum einen die /etc/iptables.up.rules:
*filter # in wie weit ist das notwendig?
:INPUT ACCEPT [0:0]https://forum.freifunk.net/t/howto-ic-vpn-setup/6672/45#
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1350
COMMIT
# Regeln zum markieren eingehender Pakete
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -i br-ffue -j MARK --set-xmark 0x1/0xffffffff
-A OUTPUT -o eth0 -p udp --dport 53 -j MARK --set-xmark 0x1/0xffffffff
-A OUTPUT -o eth0 -p tcp --dport 53 -j MARK --set-xmark 0x1/0xffffffff
COMMIT
# Route an VPN per nat.
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o tun0 -j MASQUERADE
COMMIT
Da müsste ich das Tagging raus schmeißen und das letzte MASQUERADE ja eigentlich durch irgendwas ersetzen was nur mein 10.134.0.0/16 maskiert. oder?
Quasi so: -A POSTROUTING -s 10.134.0.0/16 -o tun0 -j MASQUERADE
Wäre für mich logisch, soll nur das natten wenn die Source Adresse aus 10.134.0.0/16 kommt.
Dann habe ich da noch meine Interfaces:
# Netwerkbrücke für Freifunk
# - Hier läuft der Traffic von den einzelnen Routern und dem externen VPN zusammen
# - Unter der hier konfigurierten IP ist der Server selber im Freifunk Netz erreichbar
# - bridge_ports none sorgt dafür, dass die brücke auch ohne Interface erstellt wird
auto br-ffue
iface br-ffue inet6 static
bridge-ports none
address fd83:e002:c8a1::1
netmask 64
iface br-ffue inet static
address 10.134.10.1
netmask 255.255.0.0
# Batman Interface
# - Erstellt das virtuelle Inteface für das Batman-Modul und bindet dieses an die Netzwerkbrücke
# - Die unten angelegte Routing-Tabelle wird später für das Routing innerhalb von Freifunk (Router/VPN) verwendet
allow-hotplug bat0
iface bat0 inet6 manual
pre-up /sbin/modprobe batman-adv
pre-up /usr/sbin/batctl if add ffue-mesh-vpn
post-up /sbin/ip link set dev bat0 up
post-up /sbin/brctl addif br-ffue bat0
post-up /usr/sbin/batctl it 10000
post-up /sbin/ip rule add from all fwmark 0x1 table 42
post-up /sbin/start-stop-daemon -b --start --exec /usr/sbin/alfred -- -m -i br-ffue -b bat0;
post-up /sbin/start-stop-daemon -b --start --exec /usr/sbin/batadv-vis -- -i bat0 -s;
Hier müsste das mit dem fwmark rausfliegen, denke ich. Und das was du oben bei deiner Müritz Maschine drinne hast mit rein nehmen. Richtig?
Als letztes dann die vpn_up.sh wenn der OpenVPN Schweden Tunnel hochgefahren ist:
#!/bin/sh
ip route replace 0.0.0.0/1 via $5 table 42
ip route replace 128.0.0.0/1 via $5 table 42
Puppet habe ich mir kurz die Webseite angeschaut. Ich muss Scripte anlegen die wiederum die eigentlichen Scripte dann anlegen auf den Maschinen. Das setzt voraus das ich die Syntax von allen Scripten verstanden habe die jetzt auf der Maschine irgendwas machen, und muss dann die Syntax von Puppet scripten verstehen. Zumal ich wesentlich länger bräuchte, da ich vieles durch Google Translator schieben muss, denn mit meinem Englisch ist es nicht weit her. Und Deutsche Anleitungen zu Software sind leider sehr rar gesät.
Ich sehe ein das es in Großbetrieben oder im FFRL sinnvoll ist mit duzenden Supernodes so was einzusetzen, aber doch nicht bei 3 Gateways. Da kann ich in Turnschuh Admin Manier /etc tar.gz machen und auf eine neue Maschine kopieren und dort das wieder dorthin schieben wo ich das brauche und nur die IP Adressen vielleicht noch ändern.
[quote=„Freifunker, post:45, topic:6672“]
Wäre für mich logisch, soll nur das natten wenn die Source Adresse aus 10.134.0.0/16 kommt[/quote]
Macht sicher Sinn, auch wenn das ja erst nach der Routingentscheidung gen tun0 greift, d. h. bei korrektem Routing sollte da eh’ nur Dein System verlassender Traffic aufschlagen. Korrekter ist’s allemal
Achtung, wenn Du das Tagging läßt, geht Dein DNS-Verkehr nicht mehr über den Tunnel (was ich eher als Feature denn als Bug sähe).
[quote]
[Interfaces] Hier müsste das mit dem fwmark rausfliegen, denke ich. Und das was du oben bei deiner Müritz Maschine drinne hast mit rein nehmen. Richtig?[/quote]
Yepp, die Routen zu br-ffue müssen nach table 42. Und entsprechend iif-Regeln rein, die quasi Dein altes Tagging ersetzen. Und irgendwo sollte dann wohl auch ip rule add iif icvpn lookup 42 einen Platz finden.
Schwedentunnel sollte so ok sein dann.
Ich kann Dich nicht bekehren, will das auch gar nicht. Den Vorteil an den puppet-Skripten sehe ich darin, daß sie sicherstellen, daß alles so wie geplant aufgesetzt wird, daß das jedesmal wieder gleich geschieht (sprich: ich kann das, sofern ich die Datei mit den Eingabeparametern gesichert habe, auf einer anderen Maschine erneut laufen lassen und bekommen eine 1:1 Kopie) und daß händische Änderungen an Dateien wieder zurückgenommen werden können. Und ja, durch berufliche Erfahrung habe ich das durchaus schätzen gelernt ;), wende es im Zeitalter der Wegwerf-VMs und -Container aber auch privat an.
So. Mag noch mal wer schauen? Ping auf 10.134.10.1, 10.134.20.1, 10.134.30.1 und 10.134.1.80. Sowie auf fd83:e002:c8a1::1, fd83:e002:c8a1::2, fd83:e002:c8a1::3 und fd83:e002:c8a1:0:8080:8080:8080:8080.
EDIT
Mir wurde vom Vorstand des Freifunk Uelzen e.V. aufgetragen ICVPN mit sofortiger Wirkung wieder zu deaktivieren. Angeblich ist die Performance des Netzes in die Knie gegangen. Kann ich allerdings nicht nachvollziehen. Meine Knoten performen wie eh und je.
In meiner Community hat ICVPN keinen hohen Stellenwert. Es geht vielen einfach nur darum ein Billigst Hotspot System zu haben. Überhaupt ist Innovation nicht gerne bei uns gesehen. Am Netz zu Arbeiten ist höchst verpönt. Ich hatte angekündigt in unserer Gruppe das wir nun ICVPN haben und jetzt hatten wohl einige mal etwas schlechtere Performance an ihrem Handy. Außerdem verzeichnete unsere Knoten Graphen stellenweise Lücken in der Verfügbarkeit.
Der Server auf dem ich ICVPN teste bzw. getestet habe ist kein Verein Gateway, sondern meiner. Mit dem habe ich die Community damals auch gestartet und vereint natürlich auch diverse Services wie Map usw. Zu einigen BATMAN_adv Kernel Panics hin und wieder habe ich halt auch einige Neustarts per Hand durchgeführt in den letzten Tagen. Diese Lücken in den Graphen hat nun der Vereinsvorstand als Anlass genommen mir zu untersagen weiterhin mit dem Uelzener Netz am ICVPN teilzunehmen. Da die Graphen suggerieren würden unser Netz ist nicht stabil und würde potentielle Gewerbetreibende davon abschrecken Freifunk zu etablieren.
Dabei hatte ich alle Vorkehrungen getroffen und Knoten die mit meinem Gateway verbunden waren rechtzeitig runter geschubst, so das sie ihre FastD Tunnel zu den anderen Gateways aufbauen.
[quote=„Freifunker, post:51, topic:6672“]
Der Server auf dem ich ICVPN teste bzw. getestet habe ist kein Verein Gateway, sondern meiner. […] Diese Lücken in den Graphen hat nun der Vereinsvorstand als Anlass genommen mir zu untersagen weiterhin mit dem Uelzener Netz am ICVPN teilzunehmen.[/quote]
Klingt so, als ob der Vorstand dann mal tunlichst zusehen sollte, „seine“ Dienste auf seiner Infrastruktur an den Start zu bringen. Das klingt mehr nach einem Hotspot e. V. denn einer Freifunk-Community Schade.
Klar, Lücken in den Graphen machten auch hier einige nervös, insbesondere die Statistik zu aktiven Knoten und Endgeräten wird gerne hergezeigt. Und sicher müssen wir auch nach einem Jahr der Existenz möglichst nicht nur das Fortbestehen suggerieren können, sondern auch lustige Graphen haben, die nach guter, stabiler Funktion aussehen — da die Teilnahme bei uns allerdings kostenlos ist, ist das finanzielle Risiko für Gewerbetreibende nun auch gering (841, 4300, 1043v2, kost’ alles nicht die Welt), insofern der Vorzeigedruck gering …
Naja, jede Community entscheidet für sich, welchen Weg sie gehen will. Aber bei aller Liebe, basteln und experimentieren gehört doch auch zum Freifunk! Wie auch immer; als unbezahlter, weisungsgebundener Gewehr-bei-Fuß-Admin, zumal auf meinem eigenfinanziertem Equipment, hätte ich längst ein spannenderes Hobby (z. B. dn42).
