[Wien] LuCI-Firewall - Dringende Konfigurationsänderung!

[Markus Kittenberger]

2014-04-27 11:39 GMT+02:00 Josef Semler <(spam-protected)>:

> Liebe Community,
> in den aktuellen Backfire Vienna und 0xFF-Bubbles 2014 Versionen befindet
> sich ein kleiner Konfigurationsfehler, der *bei asymmetrischen Routen zu
> einem Verbindungsabbruch* führt!
>
> Ich bitte euch daher, eure Konfiguration zu kontrollieren und
> gegebenenfalls zu korrigieren.
>

Weiters bitte ich Alle die bis jetzt in gewisserweise versuchten mit
lqmults dem olsrd assymetrisches Routen abzugewöhnen, die Verwendung der
lqmults mittelfristig wieder auf ein Minimum zu beschränken. #1

Also eben lqmults nur zum korrigieren von Funklinks welche wirklich falsch
bewertet werden #5, und nicht um permanent Routen bzw. Nodes "loszuwerden"
welche eben fehlerhaft konfiguriert waren/sind. #7 (#6)

Aja den an mehr Details (zu dem Konfigurationsfehler und dessen
Auswirkungen) Intressierten viel spass mit folgenden dem Fussnotenlabyrinth
(-;

lg Markus

#1 Denn vermutlich wird wohl in den letzen Monaten/Jahren ein grosser
Anteil der Strecken/Nachbarn welche "scheinbar" nie verlässlich
funktionierten eigentlich "nur" an der Firewall #8 eines oder mehrer
involvierter Router gescheitert sein.
Auch die oft beschriebenen Probleme bei mehreren gleich guten Routen #4,
also die teils schon ziemlich verschriehenen flappenden Routen, lagen wohl
hauptsächlich daran dass in solchen Fällen olsrd eben immerwiedermal
sekundenweise assymetreisch routet, oder aber auch permanent #2

siehe auch #7

#2 z.b. Falls die beiden Alternativrouten zu unterschiedlichen Roofnodes
(krypta,nix,tunnelserver) führen.
Oder auch da ja auf manchen Routern bei noch das bei uns
unnötige/kontraproduktive nat-treshold konfiguriert ist.

#3 siehe: #1 (-;

#4 also bzgl. der Summe aller ETX Werte

#5 Und davon gibts bei ETX metrik leider eh genug

#6 <obergscheit>Denn bei fast allen lqmults gehört der nicht
funktionierende Link/Node zumindest mittelfristig debugged und repariert,
oder zumindest der besitzer/techC (und falls die
unintressiert/"überfordert" eben andere) darauf aufmerksam
gemacht</obergescheit>

#7 Aja ein einziger Router mit drop_invalid=1 auf dem assymterischen Teil
seiner Route nach X reicht das auf der Route für seine eigene IP "nichts
mehr nach/von X geht", während aber der traffic von/zu IPs (sofern
symmetrisch) problemlos auf diesen Routen geroutet wird/wurde.

U.a. darum sind lqmults als "Lösung" für dieses Problem ja noch unpassender
als sonst *G #6

#8 im konkreten geht es um ca. derartig gelagerte firewall rules #9 in der
FORWARD chain, in der die dritte rule jeglichen traffic den das connection
tracking nicht versteht #10 dropped (cstate INVALID), bevor überhaupt die
Ausnahmen für 0xff interfaces (in dem Beispiel eth0 und wlan0) geifen
konnten.

iptables -nvL delegate_forward
Chain delegate_forward (1 references)
 pkts bytes target     prot opt in     out     source
destination
 4704 1202K forwarding_rule  all  --  *      *       0.0.0.0/0
0.0.0.0/0            /* user chain for forwarding */ # -> allerdings ist
die chain idr leer.
 3392 1049K ACCEPT     all  --  *      *       0.0.0.0/0
0.0.0.0/0            ctstate RELATED,ESTABLISHED
   78  6176 DROP       all  --  *      *       0.0.0.0/0
0.0.0.0/0            ctstate INVALID # -> verwirft eben auch assymetrischen
0xff-transit-traffic ! *G
  209 18990 zone_0xFF_forward  all  --  eth0   *       0.0.0.0/0
0.0.0.0/0           # -> hier ist nun schon zu spät für 0xff-transit
spezifische Ausnahmen!
 1025  128K zone_0xFF_forward  all  --  wlan0  *       0.0.0.0/0
0.0.0.0/0         # --,,--
    0     0 reject     all  --  *      *       0.0.0.0/0
0.0.0.0/0

#9 Der auszug ist aus ner neueren naked.bubble, aber auch viele
backfire-vienna Versionen #11 sind betroffen, auch wenn die chains dort
eben noch anders heissen.

#10 bzw eben nicht verstehen konnte weil es aufgrund von assymetrischen
routing nur eine richtung zu sehen bekommt

#11 d.h. vmtl. alle die eben eine drop_invalid firewall option haben (die
nun also auf 0 gestellt gehört!)
<snip file=/etc/config/firewall>
config defaults
        option syn_flood '1'
        option output 'ACCEPT'
        option drop_invalid '1'
        option input 'ACCEPT'
        option forward 'REJECT'
</snip>

p.s. Ein Danke auch noch an Erich Pekarek sowie eben Akku und Franz Lax die
eben unlängst gleichzeitig genug Probleme (an komplett anderen Stellen im
Netz) hatten, so dass nun mal endlich der Zusammenhang auffiel.
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/wien/attachments/20140427/03fe5d4e/attachment.htm>