Fastd Migration ohne Portwechsel

Wir hatten nun schon öfter das Problem, dass wir unsere fastd Konfiguration auf den Supernodes ändern wollten, sodass sie nicht mehr abwärtskompatibel zur Alten ist. Die MTU zu wechseln ist zum Beispiel eine solche problematische Einstellung. Die Frage ist nun, wie man die Freifunkrouter von der Alten zur neuen Konfiguration migriert.

Erstmal richtet man wohl gleichzeitig eine zweite fastd Instanz auf dem Supernode auf einem anderen Port ein. Nun rollt man eine neue Firmware für die Router aus, in der die neue Konfiguration propagiert wird. Etwas unschön hieran ist, dass man jedes mal einen neuen Port auf den Supernodes vergeben muss. Folgendes Szenario gibt es bei uns zB an einigen Stellen. Falls jemand vor dem Freifunkrouter eine sehr restriktive Firewall betreibt, die nur bestimmte ausgehende Ports zulässt, zerstört man diesen Aufbau.

Um diesen Portwechsel von Extern zu vermeiden habe ich ein wenig in den Tiefen von iptables gewühlt und bin auf „zufällige Portweiterleitung“ gestoßen. Vermutlich war diese Möglichkeit eher zur Lastverteilung gedacht, sie funktioniert aber auch super um mehrere inkompatible fastd Instanzen auf den selben Port zu bringen. Dafür ist nur folgende Regel in der nat Tabelle notwendig:

# fastd migration
iptables -t nat -A PREROUTING -p udp -m udp --dport 10000 -j REDIRECT --to-ports 10000-10001 --random

Die Regel sorgt beim Verbindungsaufbau dafür, dass man zufällig einem der beiden internen Ports zugeordnet wird. Wenn man den falschen erwischt, dann wird keine Verbindung zustande kommen und fastd wird einen neuen Verbindungsversuch in ca 30 Sekunden starteten.

Wichtig hierbei ist, dass der Verbindungsversuch von einem neuen Port kommt. Ansonsten ist die Verbindung für IPTables (genauer gesagt conntrack) nicht „neu“. Wenn man innerhalb von 30 Sekunden wieder vom gleichen Port kommt, dann kennt conntrack die Verbindung noch und man stößt wieder auf die gleiche fastd Instanz [1]. Solange man den fastd nicht explizit auf einen festen Port bindet (also die Konfigoption „bind“ benutzt), wird bei jedem Verbindungsversuch ein neuer Port genutzt. In Gluon wird kein „bind“ verwendet. Die Strategie funktioniert also. Die einzigen negativen Auswirkungen sind, dass eventuell ein paar mehr Verbindungsversuche vonnöten sind. Das ist aber bei vielen Supernodes und nur 30 Sekunden bis zu einem erneuten Versuch beim gleichen Supernode kein wirkliches Problem.

Vielleicht hilft das ja auch anderen :wink:

Gruß,
lemoer

[1] Die NAT-PREROUTING Tabelle wird nur durchlaufen, wenn eine Verbindung im conntrack Sinne neu ist.

3 Likes

edit:ich verstehe nicht ganz,
wenn neue FW mit neuer mtu ausgerollt wird - wird dort fastd nur mit der korrekten mtu funktionieren.
wenn also mehrere Supernodes oder mehrere fastd instanzen zur auswahl stehen ist das alles kein problem. die ganze rule magie brauchste nicht - bzw den gleichen Port zu nutzen für überflüssig.
Also der Wechsel von MTU läuft über Angebot an Fastd instanzen im Netz die die Firmware kennt und über eine neue FW.

@fuzzle In einer Welt ohne Resourcenlimits tritt das Problem nicht auf. Das stimmt.

1 Like

Es gibt auch Communities, die zur Vermeidung von Quertraffic (und für effizentes IPv6) bewusst nur mit einem Fastd-Server fahren.

Ich halte es für einen ziemlich genialen Hack, der sich auch in anderen Szenarien nutzen lassen wird (Batman-Migration).

2 Likes