Verbindungsprobleme über Bridge

D

dee0x400

Member
Hallo,
ich hätte eine Frage bezüglich der Konfiuguration einer transparenten Bridge.

* Kurz:
Ich hab ein Hostsystem welches mir momentan drei virtuelle Systeme hosten soll (2x debian 6.0, 1x OpenBSD 4.9).
Das Hostsystem unterstützt die VT-x-Erweiterung und die Virtualisierungssoftware ist Oracle VirtualBox 4.0.8r71778 unter Windows 7.

* Netzplan:
Code: 
 +-----------+  internalNet0  +-----------+  internalNet1  +-----------+ 
 | debian0   +----------------+ obsd      +----------------+ debian1   |
 +----+------+                +-----------+                +------+----+ 
      | eth1 |                | em1 | em2 |                | eth1 |
      +------+                +-----------+                +------+

* Legende:
debian0
- eth1: 192.168.1.1/24

debian1
- eth1: 192.168.1.2/24

obsd
- bridge0( em1, em2 )

* Configs:
obsd:
Code: 
# cat /etc/hostname.em1
up
# cat /etc/hostname.em2
up
# cat /etc/hostname.bridge0
add em1
add em2
up

Angelegt hatte ich die Bridge mal mit:
Code: 
# ifconfig bridge0 create
# ifconfig bridge0 add em1 add em2 up

Wobei das ja egal sein sollte, da ich mit /etc/hostname.bridge0 ja die permanente Lösung hinzufüge

und noch IP_Forwarding aktiviert
Code: 
# sysctl net.inet.ip.forwarding=1

bzw. auf =1 in der /etc/sysctl.conf

pf
Code: 
# cat /etc/pf.conf
set skip on lo
pass # to establish keep-state
block in on ! lo0 proto tcp to port 6000:6010 #block remote connections to X11

### general
pass in on em1 all
pass out on em1 all
pass in on em2 all
pass out on em2 all

Code: 
# pfctl -nf /etc/pf.conf gibt auch keine Fehler aus

* Problem:
Wenn ich nun von debian1 zu debian0 pinge, dann kann ich die ARP-Anfragen in Wireshark auf debian0 sehen (Who has 192.168.1.1? Tell 192.168.1.2), genauso auch umgekehrt
Das 'gepingte' System versucht auch zu Antworten (192.168.1.1 is at $MAC-Address), kommt jedoch nicht durch.

Hat da irgendwer nen Plan oder einen Ansatz wo ich nachsetzen kann?
Vlt. seh ich ja auch den Wald vor lauter Bäumen nicht mehr ... :confused:

Grüße
dee

* Zusatz:
Alle drei Systeme verfügen noch über einen weiteren Anschluß für's eine Internetverbindung, welche ich jedoch mom. zum Testen auf deaktiviert habe (# ifconfig $INTERFACE down)
 
moin

pf rules auf bridge0 interface setzen nicht auf em da diese ja bestandteil der bridge sind.

sollte aber mit tcpdump -n -e -vvvv -p -i pflog0 zu sehen sein.

holger
 
192.168.1.1/24 und 192.168.2.1/24 liegen in verschiedenen Netzen. Ohne Routing können die nicht miteinander kommunizieren.
 
Äh, stimmt, sorry...

wie sieht die route für 192.168.1.0/24 auf den debian instanzen aus?
 
mark05 schrieb:
moin

pf rules auf bridge0 interface setzen nicht auf em da diese ja bestandteil der bridge sind.

sollte aber mit tcpdump -n -e -vvvv -p -i pflog0 zu sehen sein.

holger
Zum Vergrößern anklicken....

Ok, ich hab dann mal ein pass in und pass out all für die bridge0 hinzugefügt.

Code: 
# cat /etc/pf.conf

set skip on lo
pass # to establish keep-state
block in on ! lo0 proto tcp to port 6000:6010 #block remote connections to X11

### general
pass in on em1 all
pass out on em1 all
pass in on em2 all
pass out on em2 all

### bridge
pass in on bridge0 all
pass out on bridge0 all

Das Problem besteht jedoch weiterhin.
Hatte auch mal den general Bereich auskommentiert mit dem gleichem sichtbaren Erfolg.

Den tcpdump hab ich mal probiert. Jedoch bleibt der bei mir einfach stehen.

Code: 
# tcpdump -n -e -vvvv -p -i pflog0 
tcpdump: WARNIN: snaplen raised from 116 to 160
tcpdump: listening on pflog0, link-type PFLOG

Wenn ich es abbreche kommt auch nur
Code: 
0 packets received by filter
0 packets dropped by kernel

Wenn ich nun pflog0 durch bridge0, em1 oder em2 ersetze, sehe ich die ping-anfrage (ARP-Request), jedoch auch nur in die eine Richtung (von beiden Seiten aus).
Verworfen wird jedoch auch nichts.

Code: 
12 packets received by filter
0 packets dropped by kernel

---

oenone schrieb:
Äh, stimmt, sorry...

wie sieht die route für 192.168.1.0/24 auf den debian instanzen aus?
Zum Vergrößern anklicken....

Also die routen auf den Debian's sind

Code: 
$ sudo route 
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     *               255.255.255.0   U     0      0        0 eth1

Sollte aber doch zu vernachlässigen sein, da sich die zwei Debian-Systeme ja im gleichen Netz befinden und sich so finden sollten (die Bridge ist ja 'quasi nicht sichtbar).


Vlt. ist es auch irgendwas einfaches, da ich schon lange nichts mehr mit OpenBSD gemacht hab und gerade versuche gelesenes Umzusetzen. :)
 
Zuletzt bearbeitet:
oenone schrieb:
funktioniert es, eine ssh-verbindung aufzubauen?
Zum Vergrößern anklicken....

Nein.
Ich hab's auch frequentiert probiert, da ich mir nicht sicher war, ob pf den ping blockt. Der ssh-client terminiert mit 'No route to host'.

Ich hab mir eben noch nen alten PIII mit zwei Netzwerkinterfaces aufgesetzt.
Dann werd ich überprüfen ob das Problem auch nativ auftritt, da mir die Erfahrung mit virtuellen BSD-Systemen fehlt.
 
Coole Sache ...

... bin jetzt gerade über meine lokale nativ OpenBSD-Bridge im Netz.
Auf anhieb mit den Einstellungen aus den Posts.

Code: 
# tcpdump -n -e -vvvv -p -i bridge0

ist im absoluten Redefluß ...

Also scheint's wohl irgendwie mit der Virtualisierung zu tun haben, da die Einstellungen an sich ja richtig sein müssten.

Und weiter geht's
Dann werd ich mal weiterschauen, was noch so geht oder ob's ein Bug ist ...
Werde mal ein Topic im VirtualBox-Forum zu dem Problem eröffnen und euch auf dem laufenden halten.
Wenn die auch nichts wissen, werd ich wohl nächste Woche mal VMWare installieren und testen ob's dort die gleichen Probleme gibt.

Aus der Sicht der Bridge könnte man den Topic 'Solved' setzen, aus Sicht der Virtualisierung nicht. Bin mir da jetzt auch noch bisschen unschlüßig, da es für mich nur als Teillösung zu sehen ist.

Wenn ihr noch Ideen oder Anregungen haben solltet, nur her damit.
Auf jeden auch schonmal danke an alle für die Hilfe, eine Produktivlösung haben wir ja schonmal. :)
 
hi

da faellt mir gerade auf.

woher soll openbsd wissen was es layer3 maessig tun soll ? er kennt weder das eine
noch das andere netz.

wenn du beiden debians eine ip aus dem gleichen netz gibt z.b.

192.168.1.1 und 192.168.1.2 das koennen die miteinander reden.

wenn openbsd auch als layer 3 router fungieren soll muss er auch die netze kennen.

holger
 
mark05 schrieb:
hi

da faellt mir gerade auf.

woher soll openbsd wissen was es layer3 maessig tun soll ? er kennt weder das eine
noch das andere netz.

wenn du beiden debians eine ip aus dem gleichen netz gibt z.b.

192.168.1.1 und 192.168.1.2 das koennen die miteinander reden.

wenn openbsd auch als layer 3 router fungieren soll muss er auch die netze kennen.

holger
Zum Vergrößern anklicken....

Das stimmt schon, aber soll das OpenBSD nicht.
Das OpenBSD-System soll nur als transparente Bridge mit Firewall fungieren und die müsste dann doch eigentlich, von der Bridge her, auf layer2 sein.
Denn durch die Bridge verbinde ich interace em1 virtuell mit em2, so dass ohne Firewall einfach nur sämtliche Pakete durchgeleitet werden.

In einem eingesetzten Netzwerk würde ich die dann zwischen Router und internem Lan setzen, damit auf der Bridge gefiltert werden kann (pf), diese aber nicht direkt erreichbar ist.

Code: 
 Internet ------ Router ------ Bridge ------ Switch ------ Internes-Netzwerk
 
richtig aber layer 2 routed nix ..

von daher kann debian1 netz auch nix vom debian2 netz kennen

dafuer ist eine router noetig , und ein jeweilger eintrag default gateway auf den endrechnern.


holger
 
mark05 schrieb:
richtig aber layer 2 routed nix ..

von daher kann debian1 netz auch nix vom debian2 netz kennen

dafuer ist eine router noetig , und ein jeweilger eintrag default gateway auf den endrechnern.


holger
Zum Vergrößern anklicken....


Genau,
beide Debian-Systeme sind im selben Netz und die ''Standardroute'' vom eigenen Netz ist ja gegeben.
Das InternalNet0 und InternalNet1 kommt aus der Virtualisierung und bedeutet einfach nur soviel wie, da steckt ein Netzwerkkabel drinne (Repräsentation der physikalischen Trennung), aber kann ich oben ja mal ergänzen.
Ein Gateway etc. ist absichtlich rausgehalten um das Problem so einfach wie möglich zu halten. Also das es echt nur um ne Bridge geht und wie gesagt, in meinem Aufbau mit nem alten PIII läuft die Config so ohne Probleme (hab ich z.B. gestern die Posts hier gemacht)

Wahrscheinlich werd ich morgen oder am Dienstag das ganze auch mal mit VMWare testen. Ansonsten muss ich wohl noch bisschen Hardware an die FH schleppen ... :)
 
Unter VMware Workstation läuft's

So, hab jetzt eben mal die VMware-Variante probiert.

Was ich jetzt bis eben gesehen habe:
  • VirtualBox
    Auf der Bridge geht jeweils nur eine Richtung durch die Bridge durch ... ???
  • VMware Player
    Virtuelle Netzwerke sind nicht wirklich vorhanden bzw. über einen Trick zu ergänzen.
    http://www.windowspro.de/andreas-kroschel/vmnetcfgexe-fuer-vmware-player-3
    Ich hab's aber irgendwie nicht ganz verstanden und auch keine Lust mehr gehabt.
  • VMware Workstation
    Läuft direkt und ohne Probleme!
    Die Virtual-Network-Einstellung ist auch direkt verständlich.
    Einzig, es ist ne 30-Tage-Probeversion.

Werd wohl mal VirtualBox kontaktieren ob die das Problem kennen. Im Forum hat sich auf jeden mal noch niemand gemeldet.

Dann kann ich jetzt mal mit pf starten
 
2 verschiedene ip netze ohne default gateway kennen sich nicht .
egal ob bridge oder switch .


man kann zwar die verschiedenen packete sehen mit tcpdump aber die rechner koennen sich
nicht unterhalten weil sie nicht das jeweilige andere netz kennen.

alternativ kann man beiden rechnern jeiweils eine ip aus dem anderen netz geben
dann funktioniert das auch.

das ist ip ... und hat nix mit der virtualisierungs technik zu tun.


holger
 
mark05 schrieb:
2 verschiedene ip netze ohne default gateway kennen sich nicht .
egal ob bridge oder switch .


man kann zwar die verschiedenen packete sehen mit tcpdump aber die rechner koennen sich
nicht unterhalten weil sie nicht das jeweilige andere netz kennen.

alternativ kann man beiden rechnern jeiweils eine ip aus dem anderen netz geben
dann funktioniert das auch.

das ist ip ... und hat nix mit der virtualisierungs technik zu tun.


holger
Zum Vergrößern anklicken....

Die beiden Rechner sind doch im gleichen Netz oder verstehe ich an der VirtualBox-Einstellung etwas falsch?

So wie ich das verstehe:
InternalNetwork heißt hier soviel wie Patchkabel.
Also ich simuliere nur eine physikalische Verbindung über zwei Patchkabel.
D.h. beide Debian-Systeme sind im gleichen Netz (192.168.1.0/24).
Ich brauche diese simulierte Trennung, da sonst der Verkehr nicht mehr durch die Bridge geht, sondern sich direkt zwischen den zwei Debian-Systemen abspielt.

Also InternalNetwork != Rechner-Netzwerk.
Physikalisch meine ich diesen Aufbau:

Code: 
 +---------+                   +--------+                   +---------+
 | debian0 +----patchkabel0----+ bridge +----patchkabel1----+ debian1 |
 +---------+                   +--------+                   +---------+

Dieser funktioniert bei mir auch nativ, genau so auch unter VMware-Workstation.
Unter Virtualbox kommt der Ping ja auch auf der einen Seite an und der Partner versucht ein Pong abzusetzen. Dieser kommt jedoch nicht mehr durch die Bridge zurück, womit ich, bei gleicher Config, auf ein Problem bei VirtualBox schließe.
 
ups habe gerade den ersten post nochmal gelesen ,
ich danchte die ganze zeit es geht um 2 ip netze.

bei den bridge mal spanning tree checken .

holger
 
@dee0x400: du solltest vielleicht ein interface von der Bride noch mit einer IP aus dem Netz versorgen, damit du auch remote an die kiste dran kommst (du darfst allerdings auch nur ein Interface mit einer IP versehen). Was dann rein oder raus darf, kannst du anschließend mit pf festlegen.
 
mark05 schrieb:
ups habe gerade den ersten post nochmal gelesen ,
ich danchte die ganze zeit es geht um 2 ip netze.

bei den bridge mal spanning tree checken .

holger
Zum Vergrößern anklicken....

Also ich schieb es momentan auf VirtualBox.
Ich muss meine Ausarbeitung jedoch nächste Woche präsentieren und VirtualBox hat mich schon ~ zwei Wochen gekostet ...
soll heißen, ich werd's wohl erst später nochmal checken.
Geb aber dann laut. ;)

makenoob schrieb:
@dee0x400: du solltest vielleicht ein interface von der Bride noch mit einer IP aus dem Netz versorgen, damit du auch remote an die kiste dran kommst (du darfst allerdings auch nur ein Interface mit einer IP versehen). Was dann rein oder raus darf, kannst du anschließend mit pf festlegen.
Zum Vergrößern anklicken....

Ja, die Bridge ist auch nur ein Teil der Lösung.
Im ganzen soll das ne Failover-Firewall-Lösung geben und da wäre auch noch ein virtuelles Adminnetz mit drinne. Aber wenn mein NAT auf der Firewall weiter nen Syntax-Fehler wirft, werd ich bestimmt nochmal so ein schönes ASCII-Bildchen posten. ^^

oenone schrieb:
VirtualBox ist halt auch nur Software und enthält wie jede andere ebenfalls Bugs.
Zum Vergrößern anklicken....

Jap, so seh ich das auch.
Nur die Zeit is schon ärgerlich, bzw. eigentlich der damit entstehende Zeitdruck ...
 
hi
nur mal so grundsaetzlich

ich selber betreibe einen router / firewall mit bridge .


die hardware hat insgesamt 5 x ethernet und 1x wlan als interfaces.

1x ethernet ist fuer das dsl modem , die anderen laufen als bridge wobei die auch eine
ip hat da die box auch als router fuer die rechner fungiert.

im prinzip so eingerichtet wie hier beschrieben
http://www.openbsd.org/faq/faq6.html

nur das ich nicht dchp fuer das interface verwende und dsa es insgesamt 4 interfaces
sind.

die wlan karte hat ein eigenes netz.


alle "ethernet" rechner die an der bridge angeschlossen sind koennen mit einander , mit wlan netz und internet sprechen .

pf laeuft auf dem wan if .

wenn du eien bridge in ha bereich laufen lassen willst musst du aufjedenfall dich mit
spanning tree und bridge prioritaet beschaftigen.

holger
 
Die Bridge läuft ja nun eigentlich bei mir.
Eigentlich, da momentan noch nicht unter VirtualBox (über die native Lösung hab ich auch schon hier im Forum gepostet).

Momentan hab ich nur einfach nicht die Zeit das Problem, bei einer VirtualBox-Virtualisierung, weiter zu verfolgen. Ich werd's aber in meiner Doku unter Zukunftsorientierte-Aufgaben anhängen. Wenn ich die Virtualisierungskiste über das Semester hinaus noch bisschen ärgern darf, dann auch gerne ich selbst. :)

Aber danke auf jeden für die Hilfe. :)

Kann ja mal ein paar Worte zum Ablauf schreiben.
Ich wollte endlich mal wieder was mit OpenBSD machen und dieses pfsync hatte mich schon damals (auf'm 3.5er cover) beschäftigt, aber ich hab irgendwie nie den Anfang gefunden (was auch immer war). Jetzt brauchte ich noch eine Projektarbeit und naja, mir ist sofort pfsync wieder eingefallen. ;)

Also hab ich da wieder angesetzt und ich fand immer das ne Bridgewall ne geniale Sache ist, also ran. Nachdem die Bridge jetzt nativ und in VMware läuft, hab ich mich mal mit CARP + pf + pfsync auseinandergesetzt und find's echt genial. Ich dachte bei pfsync an eine völlig andere Handhabung und find's echt abgefahren. Als optionaler Teil steht auch noch was von pfauth drinne. :)

Naja, hab eben den Präsentationsablauf bekommen (ich hab 15min) und ich denke, dass die 'CARP + pf + pfsync'-Lösung eng wird (für 15min), aber wohl doch noch keiner mit sowas gearbeitet hat und somit sehr interessant wird.

gruß
dee
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben