[fli4l] fli4l als ?==?utf-8?Q?reiner Ethernet-Router

Martin Dresbach martin.dresbach at arcor.de
Mi Mär 25 19:59:24 CET 2015


Hallo Matthias.

Zitat:
> Der IPCop kann standardmäßig ein Netz nur für den Betrieb von
> WLAN-Geräten vorsehen. Das andere Netz (192.168.11.0) dient dem
> Anschluss von "normalen" PC's.

Hmm, ich wüsste jetzt mal gern wo da technisch der Unterschied liegen
soll... Könnte mir eventuell nur vorstellen, dass der IPCop für dieses
"exklusive WLAN-Netz" Client Isolation betreibt oder sowas in der Art.
Ist aber nur reine Spekulation.

Zitat:
> Und ja, die "Gegenstelle" hat jetzt entsprechend neu:
> 192.168.11.10.
> Der fli4l hat jetzt IP_NET_1: 192.168.11.11.
> 
> Entsprechend gibt es auch eine Routing-Regel:
> IP_ROUTE_N='1'
> IP_ROUTE_1='0.0.0.0/0 192.168.11.10' # default route zum IPCop

Soweit schon mal richtig!

Zitat:
> Ich verstehe die Doku so, dass eine Postrouting-Regel nur dann
> nötig ist, wenn maskiert werden soll. Das will ich ja aber gerade
> nicht. Es scheint kompliziert (grübel).

Nicht so ganz. So weit ich weiss, musst du das Maskieren mit einer
ACCEPT-Regel "abschalten". Also so zum Beispiel:
PF_POSTROUTING_N='1'
PF_POSTROUTING_1='IP_NET_1 IP_NET_2 ACCEPT BIDIRECTIONAL'

Zitat:
> FORWARD-Regeln für die Subnetze der IPCop-verwalteten Netze zum
> fli4l brauche ich so nicht mehr, da aus der DMZ nichts in die anderen
> Netze dringen darf und das für WLAN ursprünglich vorgesehene Netz
> jetzt nicht mehr genutzt wird. Ich leite also nur noch vom fli4l zum
> IPCop und von dort ins WAN.

Das heisst also dann, dass dein ursprünglicher Plan auch hinfällig
ist. Sprich, ein Zugriff von den WLAN-Clients am Fli in die DMZ oder ein
anderes Netz am IPCop wäre somit auch nicht mehr möglich (bzw.
gewünscht?). Ansonsten bräuchtest du nämlich sehr wohl entsprechende
(zusätzliche) FORWARD-Regeln, wenn du nicht (zwischen IPCop und Fli)
maskierst.
Wenn also reiner WAN-Zugriff gewünscht ist, brauchst du auf jeden Fall
mindestens diese Regel:
PF_FORWARD_1='IP_NET_2 ACCEPT'

Zitat:
> Die andere Richtung ist irrelevant.

Wie Christoph schon erklärt hat, stimmmt das nicht. Die Pakte aus dem
WAN (oder bei Bedarf natürlich auch aus anderen Netzen) müssen ja auch
wieder an die WLAN-Clients vom Fli zurück geroutet werden.
Dafür braucht der IPCop auf jeden Fall die expliziten Routen zurück zu
den WLAN-Clients am Fli!

Zitat:
> Das Interface 192.168.11.10 des IPCop weist momentan einfach alles
> ab, weil es dort keine Input- oder Pre-Routing-Regel zur Behandlung
> gibt.

Ähm, ist das jetzt ein Fakt, oder eine versteckte Frage?

Zitat:
> Zum WLAN:
> 1) ja, die Karte kann master-mode. Mit Kanal 13 erfolgreich
> getestet
> 2) laut Doku für 802.11n 36 und höher. Für diese Kanäle kann man
> die größere Bandbreite (40 MHz) nehmen (Zusatz "N"), wenn ich die
> Doku richtig verstehe. Ich hätte jetzt mal 36N eingestellt. Das
> sollte konfliktfrei möglich sein.
> 3) teste ich, wenn die neue HW da ist
> 4) ganz brav habe ich DE eingestellt Smile IMHO sind da die Kanäle
> 36ff. (mit Einschränkungen: Wetterradar usw.Wink auch zulässig
> (sonst kann es nicht gehen, da hast Du recht)

Zu 1: Sehr gut. :)
Zu 2: Das ist so nicht richtig! Es git ja zwei Frequenzbereiche, 2,4 GHz
und das 5 GHz. Wenn ich das richtig im Kopf habe, kann deine Karte nur
das 2,4 GHz-Band. Damit stehen dir lediglich (in Deutschland) die
Kanäle 1-13 zur Verfügung. Die Option mit 40 MHz Kanalbreite geht da
aber auch, wenn es deine "Nachbarschaft" zulässt. Ist die Netzdichte zu
hoch oder zu dicht an deinem Kanal, schaltet der hostapd nämlich
ungefragt auf 20 MHz zurück.
Zu 3: Das solltest du auch jetzt schon machen...
Zu 4: Das muss nicht heissen, wenn die REGDOMAIN im EEPROM der Karte
nicht stimmt. Sollte da ein Update nötig sein, hab ich dazu ein HowTo
im Wiki geschrieben. Da ist dann aber definitiv Vorsicht geboten!!!
Sollte also erst mal die letzte Option für dich sein, besonders weil du
ja auf neue Hardware wartest... :)

Liebe Grüße,
Martin




Mehr Informationen über die Mailingliste Fli4L