OpenVZ zwei IP-Netze Problem

T

tomic

New Member
Hallo zusammen,

ich habe 2 Server, auf denen jeweils 2 virtuelle Server durch OpenVZ verwaltet werden. Im Anhang habe ich zur Übersicht ein Bild erstellt.

Jeder OpenVZ-Container hat eine config, in welcher wie üblich geregelt wird, welche Eigenschaften die virtuelle Maschine haben soll.

Nun habe ich in den jeweiligen Container-Configs zwei unterschiedliche IP-Adressen eingetragen, da die interne Kommunikation über ein eigenes Netz abgewickelt werden soll.

Beispiel: (Namen und IP-Adressen wurden durch X verfälscht)
VZ 1 Konfigurationsdatei:
Code: 
VE_ROOT="/var/lib/vz/root/$VEID"
VE_PRIVATE="/var/lib/vz/private/$VEID"
OSTEMPLATE="debian-6.0-amd64-minimal"
ORIGIN_SAMPLE="vps.basic"
HOSTNAME="XXhostname.domainXX"
IP_ADDRESS="94.xxx.159.25 10.11.0.125"
NAMESERVER="217.XX.XXX.25"
NAMESERVER="217.XX.XXX.18"
NAME="ve125"

Problem:
Innerhalb eines Hosts kann ich von jeder VZ die auf dem gleichen Host befindliche VZ anpingen. Innerhalb eines Hosts funktioniert also alles super.
Ping VZ1 über (10er IP und 94er IP) -> VZ2 funktioniert bzw. kommt an. Ein Ping von VZ2 (Host1) über 10er IP auf VZ4 (Host2) funktionert ebenfalls.

Aber ich erreiche von VZ1 (Host1) über die interne IP (10er) den VZ4 (Host2) nicht. Wenn ich nun VZ4 ins gleiche öffentliche Netz (IP-Adresse ändern) bringe, dann funktioniert es - aber sobald ich eine VZ auf Host 1 im öffentlichen Adressbereich X habe, kann ich "keine" VZ auf Host 2 im öffentlichen Adressbereich Y über die interne IP (10er) erreichen.

Wenn ich nun die Reihenfolge der IP-Adressen in der Konfig der VZ's ändere, also zuerst die 10er IP angebe, dann funktioniert der Ping im 10er Netz auf alle VZ's, aber dann komme ich mit diesen VZ's nicht mehr online um updates usw. zu machen. Außerdem funktioniert dann ein Ping über die öffentliche Adresse von VZ1 auf VZ4 nicht mehr.

Beispiel:
VZ1: ping 94.xxx.139.140 -> ok
VZ1: ping 10.11.0.111 -> ok
VZ1: ping 94.xxx.139.133 -> ok
VZ1: ping 10.11.0.105 -> not ok

Im ersten Moment hört sich das nach einem Routing-Problem an. Komme aber bislang zumindest auch durch manuelles setzen von Routen nicht ans Ziel.

Im Netz gibt es einige Thread zu diesem Thema, welche aber nicht beantwortet wurden - vielleicht habe ich Glück.

Über Hilfe würde ich mich sehr freuen.
 

Attachments

  • Struktur.jpg
    Struktur.jpg
    57.7 KB · Views: 346
tomic said:
Im ersten Moment hört sich das nach einem Routing-Problem an. Komme aber bislang zumindest auch durch manuelles setzen von Routen nicht ans Ziel.
Click to expand...

Wie sind die virtuellen Server auf dem Host angebunden, routed oder bridged?
 
In meiner sysctl.conf ist folgendes dazu eingestellt.

Code: 
#Open VZ settings
net.ipv4.conf.all.rp_filter=1
net.ipv4.icmp_echo_ignore_broadcasts=1
net.ipv4.conf.default.forwarding=1
net.ipv4.conf.default.proxy_arp = 0
net.ipv4.ip_forward=1
kernel.sysrq = 1
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.eth0.proxy_arp=1

Ansonsten ist es eine über apt-get install durchgeführte Installation von OpenVZ.
 
dev said:
Ich habe leider nicht die Zeit, mir alles genau anzuschauen… Hast Du das eingestellt?
Click to expand...

Ja, hier meine vz.conf

Code: 
## Global parameters
VIRTUOZZO=yes
LOCKDIR=/var/lib/vz/lock
DUMPDIR=/var/lib/vz/dump
VE0CPUUNITS=1000

## Logging parameters
LOGGING=yes
LOGFILE=/var/log/vzctl.log
LOG_LEVEL=0
VERBOSE=0

## Disk quota parameters
DISK_QUOTA=yes
VZFASTBOOT=no

# Disable module loading. If set, vz initscript do not load any modules.
#MODULES_DISABLED=yes

# The name of the device whose IP address will be used as source IP for CT.
# By default automatically assigned.
#VE_ROUTE_SRC_DEV="eth0"

# Controls which interfaces to send ARP requests and modify APR tables on.
NEIGHBOUR_DEVS=all

## Fail if there is another machine in the network with the same IP
ERROR_ON_ARPFAIL="no"

## Template parameters
TEMPLATE=/var/lib/vz/template

## Defaults for containers
VE_ROOT=/var/lib/vz/root/$VEID
VE_PRIVATE=/var/lib/vz/private/$VEID
CONFIGFILE="basic"
DEF_OSTEMPLATE="centos-5"

## Load vzwdog module
VZWDOG="no"

## IPv4 iptables kernel modules
IPTABLES="ipt_REJECT ipt_tos ipt_limit ipt_multiport iptable_filter iptable_mangle ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_length"

## Enable IPv6
IPV6="no"

## IPv6 ip6tables kernel modules
IP6TABLES="ip6_tables ip6table_filter ip6table_mangle ip6t_REJECT"
 
Ich glaube Du musst in deinen Hosts noch Host-Routen zu den VZn eintragen, damit dein Proxy-Arp funktioniert.

Im Moment bleiben (ausgehend von Host1/VZ1) die Arp-Anfragen nach zb. 10.11.0.126 unbeantwortet.

Ich kann mich aber auch irren, schau trotzdem mal die Arp-Tabellen an, das könnte aufschlussreich sein.
 
irritierend daran ist einfach nur, dass solange sich beide VZ's im gleichen öffentlichen Netz befinden, klappt der Ping sowohl über die öffentliche als auch die interne IP. wenn jedoch die VZ's auf dem anderen Host eine andere öffentliche IP hat, klappt der Ping über die interne IP nicht mehr.
Was hat denn die externe IP mit dem Ping mit der internen IP zu tun?

Was müsste denn in der arp-tabelle stehen?
 
Zu erstmal solltest du die Frage nach bridged oder routed sauber beantworten. Das ist nämlich entscheidend für die Problemlösung. Deine Config-Auszüge lassen routed vermuten. Dein Bildchen lässt bridged vermuten (eth0 != venet0).

In deinem Fall musst du innerhalb der VE eine Route für das private Netz mit der Source IP der jeweiligen VE setzen. Ansonsten wird grundsätzlich immer die zuerst zugewiesene IP als ausgehende IP verwendet.
Auf dem gleichen Host fällt ein Ping von öffentlicher auf private IP erstmal nicht auf, weil das Hostsystem problemlos alle Routen in alle Richtungen kennt. Erst wenn der Traffic das Hostsystem verlässt, muss man ernsthaft drauf achten, mit welcher Source IP man raus geht.

Virtuozzo ist dafür vor 2 Jahren angepasst worden, damit man IPs mit Subnetmask der VE zuweisen kann. Dann wird die Route von Virtuozzo automatisch erzeugt. OpenVZ hat diesen Patch IMHO noch nicht bekommen.
 
@Firewire2002
Die Frage ob bridged oder routed kann ich nicht beantworten, da ich nicht weiß, wo ich das herauslesen/finden könnte. Woran erkenne ich das bzw. wo muss ich dazu nachsehen? Es handelt sich wie gesagt um eine normale Standardinstallation von openvz, in welcher nichts spezielles gemacht wurde, außer dass die vz.conf und die sysctl.conf angepasst wurden. (siehe oben).

Ob die VZ's bridged oder routet angebunden sind hängt also davon ab, was OpenVZ hier als Standard macht, denn wissentlich darauf Einfluss genommen habe ich nicht.
---
Hat vielleicht jemand einen Tipp für passende OpenVZ-Lektüre? Finde bei den gängigen Händlern nichts passables. Doku gibts natürlich massig im Netz, aber mit einem Buch in der Hand fällt es (zumindest mir) leicher.
 
Hinweis dazu hab ich doch schon gegeben. Was hast du für Interfaces in der VE? eth oder venet? Bei ersterem hättest du auch veths auf dem Hostsystem und müsstest noch eine Bridge anlegen.
Routed ist Standard. Davon bin ich auch ausgegangen und hab dir die Lösung für dien Problem oben nieder geschrieben.
 
@dev
Danke

Wie sollte ich also nun vorgehen um min Problem zu lösen?

Wenn ich in einer der VZ's route eingebe, erscheint folgendes:

Code: 
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.0.2.1       *               255.255.255.255 UH    0      0        0 venet0
default         192.0.2.1       0.0.0.0         UG    0      0        0 venet0

Also habe ich es richtig verstanden, dass jede VZ immer ausgehend die IP benutzt, die zuerst in der jewieligen Containerconfig definiert ist?


Update:
Code: 
venet0    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:127.0.0.1  P-t-P:127.0.0.1  Bcast:0.0.0.0  Mask:255.255.255.255
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
          RX packets:128993 errors:0 dropped:0 overruns:0 frame:0
          TX packets:115050 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:17527964 (16.7 MiB)  TX bytes:15707289 (14.9 MiB)

venet0:0  Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:94.XXX.159.25  P-t-P:94.XXX.159.25  Bcast:0.0.0.0  Mask:255.255.255.255
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1

venet0:1  Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.11.0.125  P-t-P:10.11.0.125  Bcast:0.0.0.0  Mask:255.255.255.255
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
 
Last edited by a moderator:
In der VE:
Code: 
ip r a 10.11.0.0/16 src <private IP der VE>

Steht doch alles schon oben. :rolleyes:

Edit:
Ja hast du. Deswegen brauchst du die Route, damit er die richtige Source IP nimmt.
 
Firewire2002 said:
In der VE:
Code: 
ip r a 10.11.0.0/16 src <private IP der VE>

Steht doch alles schon oben. :rolleyes:

Edit:
Ja hast du. Deswegen brauchst du die Route, damit er die richtige Source IP nimmt.
Click to expand...


Kannst du mir bitte den Befehl genauer erklären?
<private IP der VE> Ist damit die IP der anderen VE gemeint, welche bisher nicht erreicht werden konnte?

Update: habe mir eben das Bild erneut angesehen, bei den einzelnen VE's habe ich eth0 stehen, kopiert von der Host - also typischer copy&paste Fehler, welcher wie schon gesagt wurde einen gravierenden Unterschied macht.
 
  • "ip" ist ein Tool.
  • "r" ist eine Kurzform von "route"
  • "a" ist eine Kurzform von "add"
  • "10.11.0.0/16" ist laut Bild dein privates Netz
  • "src" ist eine übliche Bezeichnung für "Source" also Quelle
  • "<private IP der VE>" meint natürlich die IP der VE in der du den Befehl ausführst. :rolleyes:

Für alles weitere hilft logisches Denken und manpages lesen.
 
Wenn ich in VE 1 den genannzen Befehl ausführe erscheint folgendes:

Code: 
VE1 (interne IP: 10.11.0.125)
ip r a 10.11.0.0/16 src 10.11.0.125
RTNETLINK answers: No such device
 
Firewire2002 said:
Code: 
ip r a 10.11.0.0/16 src 10.11.0.125 dev venet0
Click to expand...

@Firewire2002
Es funktioniert. Vielen vielen Dank.

ip r a 10.11.0.0/16 src 10.11.0.125 dev venet0
ich verstehe zwar, was mit diesem Befehl gemacht wird, aber den Hintergrund verstehe ich nicht. Kannst du mir das bitte noch erklären?

Was für eine Route legt der Befehl genau fest und wie bekomme ich die VE dazu, die Route nach einem Neustart noch gespeichert zu haben? Geht das auch ohne init.d script? die interfaces ist auch keine gute Lösung, da diese von Openvz beim starten immer neu geschrieben zu werden scheint.
 
Deine VE hat 2 IPs. Per Default wird für ausgehende Verbindungen die IP genutzt, welche der VE als erstes zugewiesen wurde.
Wenn du innerhalb deines privaten Netzes kommunizieren willst, solltest du aber entsprechend mit dieser IP auch arbeiten. Die Route macht genau das, was da schon steht. Er nutzt die jeweilige Source-IP für das jeweilige Netz.

Je nach Distribution gibts unterschiedliche Wege, das rebootfest zu bekommen. /etc/rc.local geht so gut wie immer. ;)
 
Firewire2002 said:
Deine VE hat 2 IPs. Per Default wird für ausgehende Verbindungen die IP genutzt, welche der VE als erstes zugewiesen wurde.
Wenn du innerhalb deines privaten Netzes kommunizieren willst, solltest du aber entsprechend mit dieser IP auch arbeiten. Die Route macht genau das, was da schon steht. Er nutzt die jeweilige Source-IP für das jeweilige Netz.

Je nach Distribution gibts unterschiedliche Wege, das rebootfest zu bekommen. /etc/rc.local geht so gut wie immer. ;)
Click to expand...

Die Sache mit der internen Kommunikation hatte ich ganz und garnicht erwartet - da ich vermutet habe, openvz könnt hierbei unterscheiden. AUch trotz einer festen Route von Host 1 -> Host 2 klappt es nicht ohne die besagte route in der VE. Schade eigentlich.

Eine Route in die Container-Konfig packen zu können wäre auch schön, so muss nun leider ein extra bash-Script her, da die network/interfaces leider immer abhängig von der container-konfig neu generiert bzw. befüllt wird.

Nochmals vielen Dank
 
You must log in or register to reply here.
Back
Top