Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I am just playing around with OpenVZ and had no experience with virtualization before. So I have the following problems in understanding this virtual infrastructure:

I have a physical Linux server, which has an IP address (e.g. 1.2.3.4) and I have 2 virtual server instances running in OpenVZ. I want to reach both virtual servers via ssh. So what IP address should I use then?

Do I need 3 IP addresses in total?

  • one for the physical main server
  • one for the 1st virtual server and
  • one for the 2nd virtual server

or how can openVZ decide which instance to take?

share|improve this question

2 Answers 2

up vote 3 down vote accepted

Each OpenVZ VM will have it's own IP address assigned, with it's own SSH daemon running and listening on the IP address for the VM. When you want to SSH into the host, you use the host's IP address, and when you want to SSH into one of the guests, you use the guest's IP address. (When I say "IP address", you could also substitute "DNS entry that refers to the IP address").

In most ways (at least at this early stage of your learning curve), you can think about a VM as being just like a real, physical machine in all the ways that matter, as far as using it on a day-to-day basis.

share|improve this answer
    
yupp. Or if you are short on IP addresses, the host can NAT the guests, and do fixed port-forwarding for the services you use (e.g. 1022 and 2022 to port 22 of guests 1 and 2.) –  Szocske Jul 28 '11 at 14:27
    
Thanks. I have thought of something like this. I really like the openVZ stuff and hope that my confusion will be gone sometimes. :) –  High6 Jul 29 '11 at 10:04

I would defiantly suggest looking into a DNAT setup on the hardware node.

Here is my working setup (with a few things obfuscated):

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]

# DHCP
-A INPUT -i vzpb -p udp -m udp --sport 67:68 --dport 67:68 -j ACCEPT
-A OUTPUT -o vzpb -p udp -m udp --sport 67:68 --dport 67:68 -j ACCEPT

# Allow ping to and from
-A INPUT   -p icmp --icmp-type 8 -j ACCEPT
-A INPUT   -p icmp --icmp-type 0 -j ACCEPT
-A OUTPUT  -p icmp --icmp-type 0 -j ACCEPT
-A OUTPUT  -p icmp --icmp-type 8 -j ACCEPT

# All new DROP
-A INPUT -m state --state NEW -j REJECT
-A OUTPUT -m state --state NEW -j REJECT

# All non-tcp DROP
-A INPUT ! -p tcp -j REJECT
-A OUTPUT ! -p tcp -j REJECT

# username xsmith = 1234 (XX State University)
#-A INPUT -m owner --uid-owner 1234 -j REJECT

COMMIT


*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]

# SNAT (to give Internet access for the local containers)
-A POSTROUTING -p tcp -o vzpb -j SNAT --to-source 1.2.3.4
# upd is needed for DNS
-A POSTROUTING -p udp -o vzpb -j SNAT --to-source 1.2.3.4



# DNAT SSH
-A PREROUTING -p tcp -d 1.2.3.4 --dport 22 -j DNAT --to-destination 192.168.1.2
# SNAT --to-source NOT required


# DNAT Web
-A PREROUTING -p tcp -d 1.2.3.4 --dport 80 -j DNAT --to-destination 192.168.1.3
-A POSTROUTING -p tcp -d 192.168.1.2 --dport 80 -j SNAT --to-source 192.168.1.1
# --to-source required


COMMIT
  • Hardware node public: 1.2.3.4
  • Hardware node local: 192.168.1.1
  • Container local: 192.168.1.2
  • You will probably need to remove all the "-o vzpb" and "-i vzpb" because I have veth and you probably have the default venet (please read http://wiki.openvz.org/Differences_between_venet_and_veth)

Also, put this into you hardware nodes's /etc/sysctl.conf and run sysctl -p:

### OpenVZ settings (2011-01-25)
# from http://wiki.openvz.org/VEs_and_HNs_in_different_subnets

# On Hardware Node we generally need packet
# forwarding enabled and proxy arp disabled

net.ipv4.conf.default.forwarding=1
net.ipv4.conf.default.proxy_arp = 0
net.ipv4.ip_forward=1

# Enables source route verification
net.ipv4.conf.all.rp_filter = 1

# Enables the magic-sysrq key
kernel.sysrq = 1

# TCP Explict Congestion Notification
net.ipv4.tcp_ecn = 0

# we do not want all our interfaces to send redirects
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.all.send_redirects = 0

Option 2

To go even more flexible and secure, consider removing all public IPs from the hardware node and putting the above NAT configuration into a container dedicated to the purpose of NAT only. That container will need a public IP (that can be the only Public IP on that machine).

The NAT container will need MAC-level access to the public network interface so you will need to switch from VENET to VETH: http://wiki.openvz.org/Differences_between_venet_and_veth

NOTE: veth can be very secure if you firewall your bridge(s) correctly.

To do veth you would have to read this page a lot: http://wiki.openvz.org/Veth

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.