Verständnisfrage zu den Rules und Interfaces
-
Der Grund war wohl: ich habe, wie angedacht, die Gruppe - bestehend aus LAN, WLAN und OpenVPN - erstellt und das reichte schon. Aufgrund der Tatsache, dass die Bridge nirgendwo aufgeführt war bzw. keine Regeln enthielt, konnte ich nirgendwo hin.
Also wenn net.link.bridge.pfil_member auf 1 steht (default), wie besprochen, hätte ich das nicht erwartet.
Das Problem ist halt, dass es wirklich so ist. Die beiden tunables haben nach wie vor die default Werte: member 1, bridge 0.
Und warum diese Umstellung nun zu einem asymmetrischen Routing führt, kann ich mir auch nicht erklären, schon gar nicht
@un1que:Default deny rule IPv4 lo0 127.0.0.1:XXX => 127.0.0.1:6379 TCP:FPA
???
Kann ich irgendwie herausfinden, wie es zustande kommt?
TCP:FPA
Was bedeutet das?a) Du suchst nicht gern selbst
b) It's out-of-state traffic, either from expired states or from asymmetric routing.zu a) Nein, ich versuche immer erst selbst eine Lösung zu finden und erst dann nachzufragen, aber an der Stelle war ich schon recht müde (u.a. weil ich viel Zeit damit verbrachte die Aussperrung seitens der Sense zu umgehen) und habe die Frage einfach in mein Posting mit den komischen Erkenntnissen reingenommen.
zu b) Danke, schaue ich mir an.Die Frage zu tunables habe ich weiter oben beantwortet.
-
Btw. ich habe gerade nochmal in die Logs geschaut und glaube, dass die 2 Block-Meldungen seit 12 Uhr nicht mehr kommen (davor im Minutentakt), nachdem ich einiges noch hier und da nachgebessert habe (evtl. habe ich gestern auch einfach was nicht ganz korrekt eingerichtet). Wenn meinerseits nichts mehr dazu kommt, dann hat es sich erledigt.
Dann bliebe nur noch die andere Frage mit der Bridge offen.
-
Hast du deine Kiste einfach mal rebooted? Das soll ja manchmal Wunder bewirken (gerade wenn es um Interfaces und VLANs geht).
-
Sorry für die sehr sehr späte Antwort. Ich hatte privat viel zu tun und habe nur nebenbei ganz feine Sachen ausgebessert, da blieb einfach keine Zeit mehr übrig, um mich intensiv noch einmal reinzuhängen.
Also, wie ich bereits sagte, diese ganzen Probleme mit dem asymmetrischem Routing etc. treten nicht mehr auf. Es lag wohl an der Falschkonfiguration der OpenVPN Verbindungen, welche ich ebenfalls etwas umgestellt habe, als ich zeitgleich die komplette Neueinrichtung der Interfaces vornahm.
Nun, die Frage bleibt also weiterhin im Raum stehen, wieso die Bridge unbedingt zur Gruppe hinzugefügt werden muss (und es nicht ausreicht einfach LAN, WLAN hinzuzufügen), wenn doch unter Tunables member=1 und bridge=0 eingestellt sind? Ich habe gerade noch einmal die Bridge aus der Gruppe (wo all Regeln definiert sind) entfernt und wurde überall ausgesperrt (da bei Bridge nur eine einzige Block-Regel eingerichtet ist) - keines meiner LAN und WLAN Geräte konnte irgendeine Verbindung herstellen.
Habe dann auch mal versucht nur die Bridge drin zu lassen und LAN/WLAN aus der Gruppe ausgeschlossen. Alle Verbindungen funktionierten scheinbar ohne Probleme, außer dass ich wohl aus dem WLAN keinen Zugriff auf LAN-Geräte hatte.@jahonix: auch ein Neustart brachte nix. Übrigens das Raus- und Reinnehmen der Bridge in die Gruppe hat auch ohne Neustart erfolgreich (naja, wie man's nimmt :-) funktioniert. Sofort nach dem abspeichern, hatte ich keinen Zugang zu nichts und nach dem Hinzufügen der Bridge zur Gruppe - wieder überall hin.
Dank dem OpenVPN Tunnel, der auch zur Gruppe gehört, ging diesmal das Zurücksetzen zum funktionierenden Zustand recht schnell und ich musste nicht ca. 1h gegen mit der Firewall kämpfen :)Wird also wohl ein Bug sein? Die Frage ist nur, ob es ein Bug seit der 2.4 Version ist oder diese Problematik bereits seit 2.3 unentdeckt bleibt?
-
Hat keiner mehr etwas zum Thema beizutragen? :-\
Ich habe es mir noch einmal kurz angeschaut und folgendes unter der Bridge-Info gefunden:
NOTE: Only one interface on a bridge should have an IP address! Do not add multiple IP addresses in the same subnet on different bridge member interfaces. Other interfaces on the bridge should remain with an IP type of None.
Vllt. kommt mein Problem daher, dass ich sowohl LAN als auch WLAN auf none stehen habe und eben der BRIDGE eine IP + entsprechendes Subnet zugewiesen habe?
-
…wieso die Bridge unbedingt zur Gruppe hinzugefügt werden muss (und es nicht ausreicht einfach LAN, WLAN hinzuzufügen), wenn doch unter Tunables member=1 und bridge=0 eingestellt sind?
Es ist schon spät … aber je länger ich drüber nachdenke, desto komischer finde ich Dein Setup.
Du willst doch zur besseren Übersicht die Regeln in nur einer Gruppe verwalten, richtig?
Warum stehen dann die Tuneables auf "filter member" und nicht "filter bridge"? Damit hättest Du schon mal nur ein Ruleset für das lokale Gedöns.
Ob man dann die Bridge mit dem VPN Interface in einer Gruppe zusammen regeln kann habe ich nie probiert; auch, weil ich das so nie machen würde.Bringe doch erst einmal die Bridge alleine zum Laufen. Und zwar, indem Du auf der Bridge und nicht den einzelnen Interfaces regelst.
Erst wenn das geht bastele eine Gruppe und probiere weiter. -
Nene, ich habe ja jetzt bereits eine Gruppe erstellt und verwalte dort all meine Regeln für LAN, WLAN und OpenVPN Server - alles so, wie ich es mir vorgestellt habe. Also Hauptziel ist erreicht, jetzt fehlt nur das Feintuning.
Die Sache ist halt, ich verstehe nicht warum ich überall die Bridge mit reinnehmen muss, damit alles so funktioniert wie es soll und es nicht einfach ausreicht LAN + WLAN zu nehmen. Denn wenn ich jetzt die Bridge bei der Gruppe weglassen würde, wäre ich ausgesperrt und da hilft auch die Anti-Lockout Rule des LAN Interfaces kein Stück. Genauso (wenn ich mich recht erinnere) muss ich bei der Gruppe bspw. eine Regel "pass Bridge_net Bridge_net" erstellen, damit die Kommunikation zwischen den LAN und WLAN Gerätschaften stattfinden kann; evtl. auch um nicht ausgesperrt zu werden (bin mir aber nicht mehr sicher).Du willst doch zur besseren Übersicht die Regeln in nur einer Gruppe verwalten, richtig?
Warum stehen dann die Tuneables auf "filter member" und nicht "filter bridge"? Damit hättest Du schon mal nur ein Ruleset für das lokale Gedöns.Nicht nur zur besseren Übersicht, sondern auch einfacheren Verwaltung über mehrere Interfaces hinweg.
Das ist es ja - die Tunables stehen auf default, aber es funktioniert trotzdem, nur eben nicht so, wie es theoretisch sollte (trotz "filter member" wird die Bridge bevorzugt behandelt) und das finde ich eben sehr komisch :-\ Die einzige Erklärung, die ich jetzt habe: bei mir hat die Bridge eine IP mit Subnetz erhalten und nicht eines der dort zugeordneten Interfaces. Kann es das sein?Ob man dann die Bridge mit dem VPN Interface in einer Gruppe zusammen regeln kann habe ich nie probiert; auch, weil ich das so nie machen würde.
Ja, das geht, warum sollte es nicht? Ich nutze quasi ein DauerVPN auf allen meinen (mobilen) Geräten und bin so auch von unterwegs mit dem heimischen Netzwerk verbunden - zum einen zwecks Datenaustausch mit dem NAS, zum anderen als eine Sicherheitsmaßnahme für ungeschützte WLAN Netzwerke. Dabei habe ich viel mit dem policy based routing zu tun. Darum will ich nicht 2x die gleichen Regeln bei der Bridge und beim OpenVPN Server festlegen bzw. bei jeder neuen Regel / Änderung daran denken das gleiche beim OpenVPN Interface zu wiederholen. Darum halt die Lösung mit der Gruppe.
Früher, wo ich nur die Bridge für die Verwaltung der Regeln genutzt habe, lief bei mir auch alles über die Bridge und nicht auf den einzelnen Interfaces, trotz "filter member"-Tunables (also wirklich komisch das Ganze).
-
Nicht nur zur besseren Übersicht, sondern auch einfacheren Verwaltung über mehrere Interfaces hinweg.
??
Ich finde etwas einfacher verwaltbar, wenn es übersichtlich ist…Das ist es ja - die Tunables stehen auf default, aber es funktioniert trotzdem, nur eben nicht so, wie es theoretisch sollte (trotz "filter member" wird die Bridge bevorzugt behandelt) und das finde ich eben sehr komisch :-\ Die einzige Erklärung, die ich jetzt habe: bei mir hat die Bridge eine IP mit Subnetz erhalten und nicht eines der dort zugeordneten Interfaces. Kann es das sein?
Ich glaube nicht, denn so sollte die Bridge konfiguriert werden.
Nur verstehe ich immer noch nicht, warum du nicht auf der Bridge filterst sondern auf den member interfaces. Halte ich für unlogisch, unübersichtlich und somit schlechter zu verwalten. In dienem Szenario brauchst du auch keine unterschiedlichen Filter auf den Interfaces.Und dann ist auch dein Problem kein Problem mehr sondern höchstens eine Bemerkung…
-
Ich glaube nicht, denn so sollte die Bridge konfiguriert werden.
Nur verstehe ich immer noch nicht, warum du nicht auf der Bridge filterst sondern auf den member interfaces. Halte ich für unlogisch, unübersichtlich und somit schlechter zu verwalten. In dienem Szenario brauchst du auch keine unterschiedlichen Filter auf den Interfaces.Und dann ist auch dein Problem kein Problem mehr sondern höchstens eine Bemerkung…
Wie kommst du denn darauf, dass ich auf den Member Interfaces filtere? Ich habe doch direkt im ersten Satz gesagt, dass ich bereits alles, so wie gewünscht, eingerichtet habe und es über die Gruppe geregelt wird.
Ich frage mal anders, wenn es ja jetzt so komisch läuft, wäre es dann "richtiger" unter tunables auf "filter bridge" zu setzen und einfach überall die Bridge, statt den LAN + WLAN Interfaces, zu definieren?
-
Wie kommst du denn darauf, dass ich auf den Member Interfaces filtere?
vielleicht deshalb:
@un1que:… Gruppe erstellt und verwalte dort all meine Regeln für LAN, WLAN und OpenVPN Server ...
... warum ich überall die Bridge mit reinnehmen muss, damit alles so funktioniert wie es soll und es nicht einfach ausreicht LAN + WLAN zu nehmen.denn das klingt jetzt genau anders herum.
wäre es dann "richtiger" unter tunables auf "filter bridge" zu setzen und einfach überall die Bridge, statt den LAN + WLAN Interfaces, zu definieren?
ja.
Alles andere sind eher Ausnahmefälle von Sonderfällen.Aber wie passt denn die letzte Aussage jetzt wieder zu "wie kommst Du darauf, dass …" von oben?
-
Ok, ich sehe schon… ich habe mich wohl etwas unkorrekt ausgedrückt und deswegen kam es zu einem Missverständnis, sodass wir nun etwas aneinander vorbei reden. Ich versuche es noch einmal zu erklären, Schritt für Schritt:
1. unter Tunables steht das "filter member" auf 1 und "filter bridge" auf 0
2. ich erstelle eine Gruppe und dort müsste ich ja Interfaces definieren, welche zu dieser Gruppe zusammengefasst werden
3. laut Punkt 1 müsste ich für die Gruppe ja LAN, WLAN und oVPN_Server Interfaces definieren => aber es geht nicht, ich werde ausgesperrt (da auf den LAN und WLAN Interfaces keine Regeln vorhanden sind und die LAN Anti-Lockout-Rule - warum auch immer - nicht greift; wobei ich es auch mit pass-any versucht hatte)
4. erst, als ich die Bridge (ich habe bisher immer dort alle meine Regeln erstellt und verwaltet) in die Gruppe aufnahm, lief alles nach Plan - ich konnte wieder auf die Sense zugreifen und es wurden alle unter dem Bridge Interface angelegte Regeln angewandt
5. danach habe ich alle Regeln aus dem Bridge Interface in die Gruppe übertragen und soweit funktionierte nach wie vor alles wunderbar
6. nahm ich nun die Bridge aus der Gruppe raus (LAN und WLAN blieben drin), wurde ich wieder ausgesperrt; trotz Punkt 1Genau das war bisher mein Problem, welches ich absolut nicht nachvollziehen kann. Denn nach meinem Verständnis sorgt das "filter member" 1 eben dafür, dass die Regeln der einzelnen Interfaces (und nicht der Bridge) bzw. die Interfaces selbst bevorzugt behandelt werden sollen?! Dass ich es mit "filter member" 0 + "filter bridge" 1 und Löschen der LAN und WLAN Interfaces aus der Gruppe in die richtige Wege leiten kann, habe ich mittlerweile verstanden und werde es bei Gelegenheit umsetzen.
