OpenVZ: acessar servidor físico versus acessar servidores virtuais

1

Estou apenas brincando com o OpenVZ e não tinha experiência com virtualização antes. Então, tenho os seguintes problemas para entender essa infraestrutura virtual:

Eu tenho um servidor Linux físico, que tem um endereço IP (por exemplo, 1.2.3.4) e tenho duas instâncias do servidor virtual em execução no OpenVZ. Eu quero alcançar os dois servidores virtuais via ssh. Então, qual endereço IP devo usar então?

Preciso de 3 endereços IP no total?

  • um para o servidor principal físico
  • um para o primeiro servidor virtual e
  • um para o segundo servidor virtual

ou como o openVZ pode decidir qual instância tomar?

    
por High6 28.07.2011 / 12:22

2 respostas

3

Cada VM OpenVZ terá seu próprio endereço IP atribuído, com seu próprio daemon SSH em execução e atendendo no endereço IP da VM. Quando você quiser usar o SSH no host, use o endereço IP do host e, quando quiser usar o SSH em um dos convidados, use o endereço IP do convidado. (Quando eu digo "endereço IP", você também pode substituir "entrada DNS que se refere ao endereço IP").

De muitas maneiras (pelo menos nesse estágio inicial de sua curva de aprendizado), você pode pensar em uma VM como sendo uma máquina real, física, em todos os aspectos importantes, até onde usá-la em um dia para o dia-a-dia.

    
por 28.07.2011 / 15:49
1

Eu certamente sugeriria investigar uma configuração DNAT no nó de hardware.

Aqui está minha configuração de trabalho (com algumas coisas ofuscadas):

*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
  • Nó de hardware público: 1.2.3.4
  • Local do nó de hardware: 192.168.1.1
  • Local do contêiner: 192.168.1.2
  • Você provavelmente precisará remover todos os "-o vzpb" e "-i vzpb" porque eu tenho veth e você provavelmente tem o venet padrão (por favor leia link )

Além disso, coloque isso em seus nós de hardware /etc/sysctl.conf e execute 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

Opção 2

Para tornar-se ainda mais flexível e seguro, considere remover todos os IPs públicos do nó de hardware e colocar a configuração NAT acima em um contêiner dedicado exclusivamente ao NAT. Esse contêiner precisará de um IP público (que pode ser o único IP público dessa máquina).

O contêiner NAT precisará de acesso no nível MAC à interface de rede pública, portanto, você precisará alternar de VENET para VETH: link

NOTA: veth pode ser muito seguro se você firmar suas pontes corretamente.

Para fazer veth você teria que ler muito esta página: link

    
por 28.07.2011 / 22:50