openVPN + Bridge => Einige Pakete gehen Verloren - Warum?

D

dark alex

Depp vom Dienst
Morgen!

Ich setze auf meinem Server openVPN ein. Weiterhin gibt es auf seiten des Hosts (ist ein virtualisierter dedi) einen vSwitch, der jeden vServer mit den anderen und dem Host verbindet. Ein Internes Netz also.

Jetzt möchte ich, dass VPN und das interne Netz verbunden werden via bridge. Dazu erstmal ein paar Daten:

VPN-Server hat zwei interfaces, eth0 und eth1 (öffentl. IP-Addressen geändert):
eth0: IP 123.123.123.123/29 (Internetzugang)
eth1: IP 10.10.0.1/16 (Interner vSwitch)

Ähnlich sieht es auch bei allen anderen Servern aus.

Weiterhin habe ich via openvpn --mktun --dev tap0 ein TAP-Interface fix erstellt.
Der Server ist ein Debian Squeeze mit installierten bridge-utils, somit ist folgendes Setup theoretisch möglich:
Meine /etc/network/interfaces (öffentl. IPs wieder maskiert, das Subnetz von eth0 könnte hier evtl falsch sein, allerdings ist es in der echten interfaces korrekt angelegt.):
Code: 
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
	address 123.123.123.123
	netmask 255.255.255.248
	network 123.123.123.120
	broadcast 123.123.123.130
	gateway 123.123.123.121
	# dns-* options are implemented by the resolvconf package, if installed
	dns-nameservers 213.133.AAA.AAA 213.133.BBB.BBB 213.133.CCC.CCC
	dns-search firesplash.de

iface vpn0 inet static
	address 10.10.0.1
	netmask 255.255.0.0
	network 10.10.0.0
	broadcast 10.10.255.255
	bridge_ports tap0 eth1

Wenn ich nun auf diesem Server Wireshark starte, und versuche vom Client (10.10.10.1) aus auf den DHCP/DNS/AD-Server (10.10.0.2) zu pingen, bekomme ich timeouts.
Ping von client (10.10.10.1) zu VPN-Server (10.10.0.1) klappt.
Kingt, als wäre die Bridge nicht aktiv (Rahmenbedingung: Alle Server 10.10.0.x sind derzeit über den vSwitch verbunden, und damit vom VPN-Server aus über eth1 zu erreichen. Alle Clients sind via VPN angebungen und somit "physikalisch" auf tap0)... ABER:
Ping vom VPN auf Server 10.10.0.2 sowie zum Client 10.10.10.1 sind möglich
Okay... immernoch evtl. die Bridge...
Ping vom 10.10.0.2 zu 10.10.10.1 => Fehler
Ping vom 10.10.0.2 zu 10.10.0.1 => Klappt
Bridge... Ich nehem an ihr seid sicher? Dann werde ich das widerlegen:
Der Client bekommt von 10.10.0.2 DHCP-Antworten

Symptomatik:
Offensichtlich verschluckt die Bridge eine bestimmte Art von Paketen, sobald sie von eth1 zu tap0 und/oder umgekehrt gebridget müssen.
Also nicht eghen unter anderem DNS und ICMP. Dafür funktioniert aber DHCP...
Wenn ich außerdem einen tracert von 10.10.10.1 auf 10.10.0.2 mache, dauert es erst ein ganzes stück, bevor dann versucht wird über mein Standardgateway dorthin zu gelangen... (Normalerwiese müsste das über das VPN ja sofort gehen...) Die Routen im Windows Client sind korrekt.
Betroffen sind die beiden Netzteile komplett, kein Client via VPN kann keinen Server via vSwitch korrekt erreichen und umgekehrt.

Noch ein paar Details, in der Hoffnung, dass das indize gibt:

Ich habe ein Monitoring mit Wireshark gemacht bzw ich habe mit die NIC-Liste anziegen lassen, wo er die Paketzahlen anzeigt. Bei einer Bridge müssten ja auf eth1, vpn0 und tap0 dieselbe Anzahl Pakete vermittelt werden.
Allerdings sobald ich einen Ping starte, driften die Pakete auseinander: tap0 und vpn0 haben mehr Pakete als eth1 (ping von 10.10.10.1 aus)

Ausgabe von ifconfig (Wieder einige Daten maskiert):
Code: 
root@vpnserver:~# ifconfig -a
eth0      Link encap:Ethernet  Hardware Adresse 00:0c:29:XX:XX:XX
          inet Adresse:123.123.123.123  Bcast:123.123.123.130  Maske:255.255.255.248
          inet6-Adresse: <<nicht von belangen>> Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:32695 errors:0 dropped:0 overruns:0 frame:0
          TX packets:46728 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:8028945 (7.6 MiB)  TX bytes:13795404 (13.1 MiB)

eth1      Link encap:Ethernet  Hardware Adresse 00:0c:29:XX:XX:XX
          BROADCAST MULTICAST  MTU:1500  Metrik:1
          RX packets:3 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:758 (758.0 B)  TX bytes:894 (894.0 B)

lo        Link encap:Lokale Schleife
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
          UP LOOPBACK RUNNING  MTU:16436  Metrik:1
          RX packets:2928 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2928 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0
          RX bytes:410863 (401.2 KiB)  TX bytes:410863 (401.2 KiB)

pan0      Link encap:Ethernet  Hardware Adresse 56:8a:55:XX:XX:XX
          BROADCAST MULTICAST  MTU:1500  Metrik:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

tap0      Link encap:Ethernet  Hardware Adresse aa:0e:22:XX:XX:XX
          inet6-Adresse: fe80::a80e:22ff:fe64:7d88/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:19084 errors:0 dropped:0 overruns:0 frame:0
          TX packets:651 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:100
          RX bytes:5516894 (5.2 MiB)  TX bytes:85936 (83.9 KiB)

vpn0      Link encap:Ethernet  Hardware Adresse 00:0c:29:XX:XX:XX
          inet Adresse:10.10.0.1  Bcast:10.10.255.255  Maske:255.255.0.0
          inet6-Adresse: fe80::20c:29ff:fe11:8436/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:19080 errors:0 dropped:0 overruns:0 frame:0
          TX packets:631 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0
          RX bytes:5249430 (5.0 MiB)  TX bytes:82577 (80.6 KiB)


Ausgabe von brctl show:
Code: 
root@vpn:~# brctl show
bridge name     bridge id               STP enabled     interfaces
pan0            8000.000000000000       no
vpn0            8000.000c29118436       no              eth1
                                                        tap0




Soweit mal das und ich hoffe jemand hat eine Idee.
Sorry schonmal für Tippfehler und dergleichen.




UPDATE 10:13 Uhr:
Ein weiteres Monitoring zeigt:
Ping-Paket-Weg:
10.10.10.4 (anderer VPN-Client) -> 10.10.0.1 (tap0) -> vpn0 -> eth1 -> ???
Also ich sehe mit Wireshark das Paket noch auf eth1, danach ist der Weg ungewiss... Ein Test auf dem Zielserver folgt gleich noch... Ein Antwortpaket ist nicht feststellbar.
 
Last edited by a moderator:
wie siehts denn mit den IP Tables aus? Wenn die nicht korrekt konfiguiert sind, geht mitunter garnichts mit OpenVPN.

versuch auch mal ein
echo 1 > /proc/sys/net/ipv4/ip_forward

denn ohne IP Forwarding fungiert OpenVPN nicht als Gateway für dahinter liegende Netzwerke

Desweiteren kann ich dir die HowTos auf der OpenVPn Seite ans Herz legen.
Für die Erstkonfig sind sie definitiv perfekt geeignet.
 
Last edited by a moderator:
Das System läuft (ohne das gebridgete eth1) seit monaten stabil.
Es ist wirklich nur die Kommuniation zwischen den beiden Netzen über die Bridge, die Probleme macht.

ip_forward sollte eine Bridge m. E. n nicht benötigen, ist aber aktiviert.

Ich habe oben noch ein Update mit angehängt.


Bedneke:
im Prinzip ist oipenVPN kein Gateway! Beide Netze haben 10.10.0.0/16
In meiner Ansicht müsste die BRidge daher problemlos funktionieren, oder sehe ich das falsch?
 
Last edited by a moderator:
Ich glaube Problem gelöst...

VMWare hatte im vSwitch Promiscus Mode deaktiviert. Damit eine Bridge funktioniert, benötigt sie diesen aber...
 
You must log in or register to reply here.
Back
Top