[v2] Add package fff-layer3-ipv4snat #79
No reviewers
rohammer
Labels
No Label
RFC
RFT
WIP
blocked
bsp
bug
build/scripts/tools
duplicate
feature
fixed
layer3
mantis
more details required
needs changes
node
packages/fff
rejected
security
trivial
upstream
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: freifunk-franken/firmware#79
Loading…
Reference in New Issue
No description provided.
Delete Branch "ChristianD/firmware:ipv4snatV2"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
With this package it is possible to make SNAT with IPv4 on the router
The user must set a peer_ip setting in gateway.meta.peer_ip to get a single ip for peering interfaces.
At ipaddr the user must set a ip that not use in babel (e.g. 192.168.0.1/16) for the clients
With this package the ipaddr address is SNAT to the peer_ip and every router need only one
freifunk ip and can use the same ipaddr on every router.
It is a system like cgnat from big provider
Signed-off-by: Christian Dresel freifunk@dresel.systems
@ -0,0 +17,4 @@# We set the snat ruleuci set snat.@client[0].ipaddr=$ipaddruci set snat.@client[0].nat=$peer_ipHi, das ist ja richtig uebersichtlich geworden.
Ich hatte da auch einen kleinen Denkfehler drin. Alles in uci gateway ist ja fest.
Eigentlich geht es doch nur um den Schalter snat.@client[0].nat . Also ob bei dem client-netz nat gemacht werden soll oder nicht. Die $ipaddr und $peer_ip stehen ja irgendwo. Da koennte man doch einfach in network.@client[0].nat=1 machen. Unbkannte Optionen werden vom netifd ignoriert und nat gibt es noch nicht. Man koennte die Option z.B auch fffnat nennen. Die Option wird es "offiziell" nie geben. Das spart die neue config snat. Und man kann das dann auch sehr einfach ohne configuregateway einschalten.
Keine schlechte Idee, ich habs mal eben dahingehend überarbeitet.
0e9a94401ato4b5d2f2b824b5d2f2b82tobbe7510d0ebbe7510d0eto89ad973122@ -0,0 +1,7 @@if uci -q get network.client.nat; thenHier muss man auf network.client.nat=1 pruefen. Ein network.client.nat=0 ist hier auch true.
@ -0,0 +1,29 @@configure() {uci del network.client.natif uci -q get gateway.@client[0].nat; thenHier auch gateway.@client[0].nat=1. Ein =0 sollte ausschalten.
89ad973122toad5cd5eea7@ -0,0 +1,29 @@configure() {uci del network.client.natif [ "$(uci -q get gateway.@client[0].nat 2> /dev/null)" = '1' ]; thenuci -q unterdrueckt die Ausgabe auf stderr. Das 2> /dev/null braucht man dann nicht mehr.
ad5cd5eea7to9fd6807612alles mal überarbeitet. Einen Punkt überlege ich noch:
brauchen wir hier wirklich kein warning oder brechen wir da lieber mit einen ERROR ab weil die Konfiguration so nicht komplett ist? Ich bin ja fast für abbrechen.
Stimmt, eigentlich Abbruch. Ohne ipaddr geht es nicht. Es passiert zwar nix, aber ich finde es auch besser hier raus zu gehen.
9fd6807612to1efc6b3d41Da ich es mittlerweile auch als sehr sinnvoll ansehe, habe ich es dahingehend mal geändert. Ich werde das jetzt nochmal testen und dann das RFC entfernen. Mir gefällt die Lösung einfach viel viel besser.
1efc6b3d41to737fde2e56So ich hab das ganze mal getestet und eben noch 2 Fehler behoben:
/etc/init.d/firewall start ==> /etc/init.d/fff-firewall start
Die -t nat table wurde von fff-firewall nicht geflust, deshalb hab ich in
src/packages/fff/fff-firewall/files/usr/lib/firewall.d/00-prepare
noch ein
iptables -t nat -Feingebaut. Ich weiß nicht genau ob das so korrekt ist aber so geht es. Ein reines iptables -F fasst die nat table anscheinend nicht an. Bin mir da unsicher wie man das richtig macht, falls da noch Änderungen gewünscht sind bitte bescheid geben
737fde2e56todc88fafe8e[v2] RFC: Add package fff-layer3-ipv4snatto [v2] Add package fff-layer3-ipv4snatdc88fafe8eto37e7b2474737e7b24747tocafec286dbIch hab das flushen der Regeln jetzt mal in ein extra Patch ausgelagert und dort auch gleich richtig alles (nat und mangle) geflusht.
cafec286dbto0b585e5273uci del network.client.nat
durch
uci -q del network.client.nat
ersetzt um Fehlerausgabe zu unterdrücken bei configure-layer3 -c
Ich hab noch einige Anmerkungen/Fragen, bevor das in die Firmware kann..
@ -8,0 +9,4 @@iptables -X -t natiptables -F -t mangleiptables -X -t mangleAn dieser table wird mit diesem Patchset überhaupt nichts geändert. Entweder nur die nat table flushen oder analog für ip6tables ebenfalls hinzufügen.
Ich hab die hier einfach mit reingenommen damit es drinnen ist und endlich "komplett" ist sonst stolpert der nächste der dann was mit mangle macht wieder drüber. Aber du hast recht, ip6tables sollte dann auch noch mit dazu.
@ -0,0 +1,32 @@include $(TOPDIR)/rules.mkPKG_NAME:=fff-layer3-ipv4snatWarum nicht fff-layer3-snat?
Wenn einer vor hat, das für IPv6 zu implementieren (was hoffentlich nicht der Fall ist), dann braucht das ja kein eigenes Paket..)
@ -0,0 +9,4 @@return 1fiif ! ipaddr=$(uci get gateway.@client[0].ipaddr); thenecho "ERROR: No ipaddr set! For SNAT use you must set ipaddr"Hier und im Satz davor fehlt ein '.' am Ende.
Außerdem würde ich schreiben "No peer_ip set, which is required for SNAT!" und beim anderen analog.
Warum heißt die Option nat, im Fehler steht dann aber SNAT? Ich würde mich hier für eines von beiden entscheiden und dann entweder client.snat oder "which is required for client interface NAT!" schreiben.
@ -0,0 +14,4 @@fi# We set the snat configuci set network.client.nat=1network.client.nat für unser eigenes Zeug zu verwenden finde ich gefährlich. Sollte wenigstens network.client.fff-nat o.ä. sein
@ -0,0 +19,4 @@}reload() {/etc/init.d/fff-firewall startStattdessen sollte für das fff-firewall Paket ein passender reload-trigger eingerichtet werden, der die Konfiguration bei Änderungen an entsprechenden Configs neu startet.
Das haben wir im moment allerdings nicht und hat mMn auch hier erstmal nichts zu suchen. Das kann man gerne mal extra bauen. Issue aufmachen dafür?
Doch natürlich gehört das zu diesem Patchset, wenn dieses Patchset neue Firewall-Features hinzufügt, die einen neuen reload-trigger benötigen.
Aktuell gibt es reload-trigger auf "/etc/config/fff-firewall" und "/etc/config/network".
Danke für die Erklärumg im IRC, jetzt verstanden und angepasst
@ -0,0 +2,4 @@peer_ip=$(uci get gateway.meta.peer_ip)ipaddr=$(uci get gateway.@client[0].ipaddr)for ip in $ipaddr; doiptables -t nat -A POSTROUTING -s $ip -j SNAT --to-source $peer_ippeer_ip ist dafür eigentlich nicht da.
Hier gilt also wie bei #87: Eigentlich bräuchte es dafür eine Möglichkeit explizit Router-IP o.ä. zu setzen.
Auch wenn ich das immer noch nicht ganz verstanden habe... Wie weit ist #87 da schon gekommen? @jkimmel hast du da schon was vorbereitet?
#136 hätte dafür einen fix.
0b585e5273to655bee72a9655bee72a9tobedf1a2cccbedf1a2ccctob428fadeb8b428fadeb8todb1b398683db1b398683to2234c7b9cf2234c7b9cftod7994ba8d6@ -6,2 +6,4 @@iptables -Xiptables -F -t natiptables -X -t natDas wirft Fehler auf der node, da dort das modul nicht da ist.
Ich mach nen Patch, der das unabhaengig flusht. Egal was da ist und was nicht.
Kommt gleich.
d7994ba8d6toc56301fd71Bin gestern über noch einen Fehler gestolpert:
in src/packages/fff/fff-layer3-snat/files/etc/layer3.d/33-snat.conf
Zeile 4
if [ "$(uci -q get gateway.@client[0].fff-snat)" = '1' ]; then
ist fehlerhaft, wir müssen das dort natürlich aus network lesen also heißt das jetzt
if [ "$(uci -q get network.client.fff-snat)" = '1' ]; then
c56301fd71tod6acab4d75d6acab4d75to568c92f1dbrebased und angepasst auf routerip von #136
offen ist jetzt nur noch die Frage wie wir mit dem Firewall Reset umgehen mit dem Problem von @rohammer und #137
Nochmal zwei Fragen:
Außerdem: UCI kann mit '-' in option-Namen nicht umgehen.
Meine Idee war, es gleich zu haben zur network und nicht mit 2 verschiedenen Namen zu hantieren. Das der "-" nicht geht, ist jetzt dumm... ja muss man ändern darauf hab ich nicht geachtet.
Gar nicht. Da ich bisher dort 192.168/16 Adressen verwende, fallen sie durch den babeld Filter (der nur 10.50/16 und 10.83/16 zulässt) und werden nicht announced.
Das fff- ist in der Gateway-Config aber redundant und wir haben das auch überall anders nicht so gemacht.
Für die Network-Config ist das ja nur da, um die Gefahr einer Überlappung mit OpenWrt Settings zu minimieren, dort soll ja keiner manuell drin rum hantieren. In so fern sehe ich von zwei verschiedenen Namen jetzt keinen Nachteil. Sogar eher einen Vorteil, weil man nicht aus Versehen das falsche ändert, denn die Optionen verhalten sich ja nicht identisch.
Den '-' würde ich einfach durch ein '_' ersetzen.
Ok. Das gefällt mir bisher noch gar nicht, denn das lässt sich kaum sinnvoll dokumentieren. Wenn die Option aktiv ist, dann sollten da entweder passende deny-Regeln entstehen, oder schon von vornherein keine allow-Regeln.
Ist dann aber Baustelle für einen anderen Pull-Request.
Mir ist die Bezeichnung tatsächlich ziemlich egal.
'-' durch '_' ersetzen klingt gut.
Weitere Anmerkungen:
network.client.ipaddr)-i br-client)Und bissl nitpicking:
uci getfehlt das-q, was zu "uci: Entry not found"-Ausgaben führt, wennconfigure-layer3 -causgeführt wirdZum Verständnis:
Wenn ich die /etc/config/gateway bearbeite und NAT anschalte aber dann nichts weiter mache (kein configure-layer3 -irgendwas), dann aus irgendeinen Grund sich die firewall neu startet, dann kommt es zu einen ungünstigen Zustand weil die Daten aus der gateway kommen für die Firewall. Hab ich dich da richtig verstanden?
Demnach ist aber auch (oder eigentlich nur? oder?) schon das
if [ "$(uci -q get gateway.@client[0].fff-snat)" = '1' ]; then
ein Problem oder? Das if müsste auf die uci network gucken dann sollte alles passen oder verstehe ich dich da falsch?
Exakt. Das ist ja auch der ganze Grund, warum wir das überhaupt in die network config schreiben. Das meinte ich mit:
568c92f1dbto31ebb6b25931ebb6b259to7573bad3ff7573bad3ffto8152e4156a8152e4156atoe9bb70b15be9bb70b15btoff0231ffe9ff0231ffe9toad4d55c826ad4d55c826to6d1c5aaa82Bevor ich jetzt wieder lauter Kleinkram anmerke, hab ich $Zeug mal selbst gefixt:
uci get [..].ipaddrSiehe https://git.freifunk-franken.de/fbl/firmware/src/branch/snat
Danke für das Überarbeiten.
Ich hab gerade deine Version getestet und scheint hier einwandfrei zu tun. Mit den Änderungen bin ich einverstanden, schaut gut aus.
fff-layer3 pkg_release bump entfernt (siehe #202) und applied.
Pull request closed