[OpenVZ] Problem mit OpenVPN und Routing

C

Chieman

New Member
[Gelöst] [OpenVZ] Problem mit OpenVPN und Routing

Hi,

ich habe ein Problem mit meinem OpenVZ-Setup. Hab zwar einen Workaround, aber will jetzt mal langsam an die Wurzel des Problems gelangen.

Folgendes Setup:

Host hat 2 Bridges, eine für VMs mit öffentlichen IP-Adressen. br0 in meinem Fall. Diese übernimmt das Routing und hat eine eigene öffentliche IP ebenso wie eth0 des Hosts.
Ich wollte das anfangs so, aber eth0 und br0 kann ich bei Bedarf immernoch bridgen.
Weiterhin gibt es eine weitere Bridge vmbr0. Hier sind alle VMs mit privaten IPs aufgehängt.

VMs welche öffentliche und private IPs haben hängen mit den jeweiligen Interfaces an beiden Bridges.
Das hat den Zweck, dass z.B. ein Web-Server mit öffentlicher IP die Datenbank im privaten Netz erreichen kann. Das geht auch ohne Probleme.

Jetzt kommt hier noch OpenVPN ins Spiel. Und hier fangen die Probleme bei den VMs im privaten Netz an.
Das konkrete Beispiel:
Web-Server, nur über das VPN zu erreichen soll einen Datenbank-Server mit privater IP erreichen. Naiv gedacht sollte er das meiner Meinung auch tun, nachdem beide im selben privaten Netz sind. Jedoch funkt mir hier natürlich das VPN dazwischen.
Statt dass die 192.168.100.107 sich direkt auf die 192.168.100.106:3306 verbindet, muss das zuerst durch das VPN.

Hier mit falschem Passwort
Code: 
[root@web-int /]# mysql -u redmine -h 192.168.100.106 -p
Enter password:
ERROR 1045 (28000): Access denied for user 'redmine'@'[B]$pubIP-VPN-Server[/B]' (using password: YES)

Das irritiert mich.

Code: 
[root@web-int /]# traceroute 192.168.100.106
traceroute to 192.168.100.106 (192.168.100.106), 30 hops max, 60 byte packets
 1  192.168.100.106  0.044 ms  0.009 ms  0.008 ms
Code: 
[root@web-int /]# arp -a
(192.168.100.106) at 00:18:51:53:89:75 [ether] on eth0

Ist das nur eine Kleinigkeit die ich da übersehen hab?
Ich hoffe es zumindest.

Wenn ihr noch Infos braucht, nur fragen!

Grüße,

Marius
 
Last edited by a moderator:
Warum überhaupt mit veth und Bridges? Mit venet geht das wesentlich einfacher. ;)

Ansonsten bitte von allen beteiligten Systemen:
Code: 
ip a l
Code: 
ip r l

Nur vom Host:
Code: 
brctl show
 
Danke dass du dir Zeit nimmst Firewire2002!

Wir wollten einfach eth0 in den VMs bereitstellen und eben das Routing so besser kontrollieren. Vielleicht war das auch der falsche Ansatz, aber nach der Umstellung hat eigentlich alles soweit gepasst, bis auf das Problem hier.

Hier geht es um die VMs mit den IDs 107 (web-int) und 106 (db)

Hier die Ausgaben die du wolltest:

Code: 
[root@[B]web-int[/B] /]# [B]ip a l[/B]
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: venet0: <BROADCAST,POINTOPOINT,NOARP> mtu 1500 qdisc noop state DOWN
    link/void
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 00:18:51:70:0c:7e brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.107/24 brd 192.168.100.255 scope global eth0
    inet6 fe80::218:51ff:fe70:c7e/64 scope link
       valid_lft forever preferred_lft forever
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/[65534]
    inet 172.16.100.14 peer 172.16.100.13/32 scope global tun0
[root@[B]web-int[/B] /]# [B]ip r l[/B]
172.16.100.13 dev tun0  proto kernel  scope link  src 172.16.100.14
192.168.100.0/24 dev eth0  scope link  src 192.168.100.107
172.16.100.0/24 via 172.16.100.13 dev tun0
default via 192.168.100.1 dev eth0


Code: 
[root@[B]db[/B] /]# [B]ip a l[/B]
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: venet0: <BROADCAST,POINTOPOINT,NOARP> mtu 1500 qdisc noop state DOWN
    link/void
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 00:18:51:53:89:75 brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.106/24 brd 192.168.100.255 scope global eth0
    inet6 fe80::218:51ff:fe53:8975/64 scope link
       valid_lft forever preferred_lft forever
[root@[B]db[/B]/]# [B]ip r l[/B]
192.168.100.0/24 dev eth0  proto kernel  scope link  src 192.168.100.106
default via 192.168.100.1 dev eth0

Der OpenVPN-Server läuft auf dem Host:
Code: 
[root@[B]hostnode [/B]~]$ [B]ip a l[/B]
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 14:da:e9:ef:67:68 brd ff:ff:ff:ff:ff:ff
    inet $PubIP peer $PubNet brd 176.9.63.255 scope global eth0
    inet6 fe80::16da:e9ff:feef:6768/64 scope link
       valid_lft forever preferred_lft forever
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 00:18:51:03:e1:8b brd ff:ff:ff:ff:ff:ff
    inet $PubIP2 brd $PubNet2 scope global br0
    inet6 fe80::40e3:45ff:fe97:9860/64 scope link
       valid_lft forever preferred_lft forever
4: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 00:18:51:4f:7d:fa brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.1/24 brd 192.168.100.255 scope global vmbr0
    inet6 fe80::2cca:67ff:fe4e:6bed/64 scope link
       valid_lft forever preferred_lft forever
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/[65534]
    inet 172.16.100.1 peer 172.16.100.2/32 scope global tun0
6: venet0: <BROADCAST,POINTOPOINT,NOARP> mtu 1500 qdisc noqueue state DOWN
    link/void
7: sit0: <NOARP> mtu 1480 qdisc noop state DOWN
    link/sit 0.0.0.0 brd 0.0.0.0
11: veth101.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 00:18:51:03:e1:8b brd ff:ff:ff:ff:ff:ff
    inet6 fe80::218:51ff:fe03:e18b/64 scope link
       valid_lft forever preferred_lft forever
15: veth108.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 00:18:51:b0:b2:33 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::218:51ff:feb0:b233/64 scope link
       valid_lft forever preferred_lft forever
16: veth106.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 00:18:51:b9:f1:8b brd ff:ff:ff:ff:ff:ff
    inet6 fe80::218:51ff:feb9:f18b/64 scope link
       valid_lft forever preferred_lft forever
22: veth109.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 00:18:51:47:21:22 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::218:51ff:fe47:2122/64 scope link
       valid_lft forever preferred_lft forever
33: veth110.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 00:18:51:cd:6f:5a brd ff:ff:ff:ff:ff:ff
    inet6 fe80::218:51ff:fecd:6f5a/64 scope link
       valid_lft forever preferred_lft forever
34: veth110.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 00:18:51:28:85:15 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::218:51ff:fe28:8515/64 scope link
       valid_lft forever preferred_lft forever
55: veth111.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 00:18:51:ad:96:7b brd ff:ff:ff:ff:ff:ff
    inet6 fe80::218:51ff:fead:967b/64 scope link
       valid_lft forever preferred_lft forever
56: veth102.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 00:18:51:c2:fa:57 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::218:51ff:fec2:fa57/64 scope link
       valid_lft forever preferred_lft forever
57: veth102.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 00:18:51:e8:bd:cd brd ff:ff:ff:ff:ff:ff
    inet6 fe80::218:51ff:fee8:bdcd/64 scope link
       valid_lft forever preferred_lft forever
68: veth107.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 00:18:51:4f:7d:fa brd ff:ff:ff:ff:ff:ff
    inet6 fe80::218:51ff:fe4f:7dfa/64 scope link
       valid_lft forever preferred_lft forever
69: veth112.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 00:18:51:9b:d8:7d brd ff:ff:ff:ff:ff:ff
    inet6 fe80::218:51ff:fe9b:d87d/64 scope link
       valid_lft forever preferred_lft forever
70: veth105.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 00:18:51:9d:a0:75 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::218:51ff:fe9d:a075/64 scope link
       valid_lft forever preferred_lft forever
73: veth101.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 00:18:51:d1:d9:c7 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::218:51ff:fed1:d9c7/64 scope link
       valid_lft forever preferred_lft forever
74: veth200.0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 00:18:51:ae:3f:04 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::218:51ff:feae:3f04/64 scope link
       valid_lft forever preferred_lft forever
77: veth104.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 00:18:51:3b:3d:be brd ff:ff:ff:ff:ff:ff
    inet6 fe80::218:51ff:fe3b:3dbe/64 scope link
       valid_lft forever preferred_lft forever
80: veth113.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 00:18:51:32:97:3f brd ff:ff:ff:ff:ff:ff
    inet6 fe80::218:51ff:fe32:973f/64 scope link
       valid_lft forever preferred_lft forever
81: veth103.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 00:18:51:bc:f7:35 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::218:51ff:febc:f735/64 scope link
       valid_lft forever preferred_lft forever
[root@[B]hostnode [/B]~]$ [B]ip r l[/B]
$PubBRD dev eth0  proto kernel  scope link  src $PubIP
172.16.100.2 dev tun0  proto kernel  scope link  src 172.16.100.1
$PubNet2 dev br0  proto kernel  scope link  src $PubIP2
192.168.100.0/24 dev vmbr0  proto kernel  scope link  src 192.168.100.1
172.16.100.0/24 via 172.16.100.2 dev tun0
169.254.0.0/16 dev eth0  scope link  metric 1002
169.254.0.0/16 dev br0  scope link  metric 1003
169.254.0.0/16 dev vmbr0  scope link  metric 1004
default via $GW dev eth0

Code: 
[root@[B]hostnode [/B]~]# [B]brctl show[/B]
bridge name     bridge id               STP enabled     interfaces
br0             8000.00185103e18b       no              veth101.0
                                                        veth102.0
                                                        veth103.0
                                                        veth104.0
                                                        veth105.0
                                                        veth109.0
                                                        veth110.1
                                                        veth113.0
vmbr0           8000.0018514f7dfa       no              veth101.1
                                                        veth102.1
                                                        veth106.0
                                                        veth107.0
                                                        veth108.0
                                                        veth110.0
                                                        veth111.0
                                                        veth112.0
                                                        veth200.0
 
Last edited by a moderator:
Und wo sind die Daten vom VPN Server und vom Hostsystem? ;)
Eine Zuordnung der veths zu den 2 angesprochenen VEs wäre auch interessant, damit man mal sieht ob sie in der richtigen bridge hängen.

Aktuell seh ich jedenfalls keinen Fehler.
 
Wozu baust du ein VPN zwischen VE und Hostsystem? Zumal du ja sowieso schon ein privates Netz in der VE hast.
Die Routingtabellen und Interfaces sehen funktional aus.

Eventuell hast du sehr bescheidene IPTables NAT/Forward Regeln (iptables -L -n -v && iptables -t nat -L -n -v) drin oder nutzt Policy-based Routing Regeln (ip ru l).

Ich würde das VPN in den VEs aber weglassen und das Routing vom VPN in die VEs auf dem Hostsystem steuern.
 
Firewire2002 said:
Wozu baust du ein VPN zwischen VE und Hostsystem?

[...]

Ich würde das VPN in den VEs aber weglassen und das Routing vom VPN in die VEs auf dem Hostsystem steuern.
Click to expand...

Hi Firewire2002!

Das ist eben da, dass wir mit Clients eben direkt durchs VPN darauf zugreifen können.
Habe ich da einen Denkfehler in dem Setup? So dachte ich wäre es am Einfachsten...

Ansonsten auf der Hostnode:
iptables -L -n -v
Code: 
Chain INPUT (policy ACCEPT 4 packets, 128 bytes)
 pkts bytes target     prot opt in     out     source               destination
 2335  370K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED

[...]

Chain FORWARD (policy ACCEPT 249 packets, 13136 bytes)
 pkts bytes target     prot opt in     out     source               destination
 1381  445K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED

iptables -t nat -L -n -v
Code: 
Chain POSTROUTING (policy ACCEPT 772K packets, 45M bytes)
 pkts bytes target     prot opt in     out     source               destination
15535 1148K SNAT       all  --  *      *       192.168.100.106      0.0.0.0/0           to:$PubIP
  452 28773 SNAT       all  --  *      *       192.168.100.107      0.0.0.0/0           to:$PubIP
[...]
28461 1757K SNAT       all  --  *      *       172.16.100.0/24      0.0.0.0/0           to:$PubIP

ip ru l
Code: 
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default
 
Chieman said:
Das ist eben da, dass wir mit Clients eben direkt durchs VPN darauf zugreifen können.
Click to expand...

Push die Route für das Private Netz zu den VPN Clients und sie werden es erreichen.

Da hast du deinen Fehler:
Code: 
15535 1148K SNAT       all  --  *      *       192.168.100.106      0.0.0.0/0           to:$PubIP
  452 28773 SNAT       all  --  *      *       192.168.100.107      0.0.0.0/0           to:$PubIP
Beschränk die Regeln auf das Ausgehende-Interface, auf dem die PubIP tatsächlich benötigt wird und es sollte funktionieren.

Wenn Informationen verlangt werden, erwartet man die im übrigen vollständig und unzensiert. Ausser es stehen Zugangsdaten oder andere Sicherheitsrelevante Dinge drin. IPs gehören nicht dazu. :rolleyes:
 
Firewire2002 said:
Beschränk die Regeln auf das Ausgehende-Interface, auf dem die PubIP tatsächlich benötigt wird und es sollte funktionieren.
Click to expand...

Danke für deine Hilfe, das war mein Fehler. Das pushen der Route zum entfernten privaten Netz werde ich auch direkt mal testen.

Firewire2002 said:
Wenn Informationen verlangt werden, erwartet man die im übrigen vollständig und unzensiert. Ausser es stehen Zugangsdaten oder andere Sicherheitsrelevante Dinge drin. IPs gehören nicht dazu. :rolleyes:
Click to expand...

Naja die tun im Grunde nichts zur Sache. Helfen nicht und Schaden nicht.

Danke jedenfalls, dass du dir Zeit genommen hast das anzuschauen!

Schönes Wochenende noch!

Grüße
 
You must log in or register to reply here.
Back
Top