Eu sou um programador que foi empurrado para o serviço de administração de servidores, e eu tenho um problema que está me confundindo bem. A falta de conhecimento é, sem dúvida, o culpado, então me eduque se puder. :)
PROBLEMA EM BREVE: Dois servidores físicos hospedados pelo mesmo serviço de hospedagem dedicado. O servidor da Web (em execução em uma VM) em um servidor não pode ser acessado pelo outro servidor, mas pode ser acessado por qualquer outra pessoa na Internet que tente.
CONFIGURAÇÃO:
Temos dois servidores hospedados pelo ServerBeach. Ambos rodando o Debian, um rodando o VMWare Server 2 com duas VMs - cada um rodando Debian também. Cada uma das VMs está executando o Apache e disponibilizando um site. Alguns IPs falsos para maior clareza:
SERVIDOR # 1 (eth0): 10.0.1.1
SERVIDOR # 2 (eth0): 11.0.0.1
IP secundário do SERVID # 2 (eth0: 1) - para VM # 1: 10.0.2.1
IP secundário do SERVIDOR # 2 (eth0: 2) - para VM # 2: 10.0.2.2
As VMs no servidor nº 2 são conectadas em rede ao host por meio de redes somente de host:
SERVIDOR # 2 (vmnet1): 192.168.0.1
VM # 1: 192.168.0.2
VM # 2: 192.168.0.3
... enquanto as regras do iptables no Servidor # 2 levam o tráfego da Internet para esses IPs secundários e mudam o IP de destino para as VMs e de volta para o tráfego que sai da Internet para a VM:
-A PREROUTING -d 10.0.2.1 -i eth0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.0.2:80
(...)
-A POSTROUTING -s 192.168.0.2 -o eth0 -j SNAT --to-source 10.0.2.1
Isso funciona. Um computador disponível na Internet pode apontar seu navegador para o link e o servidor da Web é executado na VM. Esse tipo de configuração, em que os IPs secundários são aliases na máquina host e não residem nas próprias VMs, é como o ServerBeach insiste em configurações de VMWare como essas que devem ser configuradas. E isso faz o trabalho.
A única coisa estranha é que, quando o servidor nº 1 tenta acessar a VM do servidor nº 2 como qualquer outro cliente na Internet, o tempo limite cai. (Eu estou logado no Servidor # 1 via SSH e usando links para tentar navegar pelo site, ou até mesmo fazer telnet na porta 80)
Se eu executar o tshark na VM nº 1, vejo os pacotes SYN passarem do servidor nº 1 ao servidor nº 2 para a VM:
4.607664 10.0.1.1 -> 192.168.0.2 TCP 44983 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=318986 TSER=0 WS=7
52.596287 10.0.1.1 -> 192.168.0.2 TCP 44983 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=330986 TSER=0 WS=7
(etc...)
Os pacotes SYN continuam chegando, mas a VM nunca envia um SYN-ACK.
Agora, se eu pulo em qualquer outro computador e vou para essa URL em um navegador, vejo o SYN, o SYN-ACK e o ACK e, claro, o tráfego a seguir (chamaremos esse outro sistema de 170.0. 0,1):
8.456176 170.0.0.1 -> 192.168.0.2 TCP 16945 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=1 TSV=972883011 TSER=0
8.456243 192.168.0.2 -> 170.0.0.1 TCP http > 16945 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=718068724 TSER=972883011 WS=4
8.522374 170.0.0.1 -> 192.168.0.2 TCP 16945 > http [ACK] Seq=1 Ack=1 Win=66608 Len=0 TSV=972883012 TSER=718068724
(... let the GETs begin! ...)
A mesma coisa acontece na VM # 2. Todos podem entrar em contato e se comunicar com o servidor da web exceto Server # 1.
O Servidor # 1 pode, é claro, acessar qualquer outro site na Internet.
EDIT: Se eu executar o nmap -sS 10.0.2.1 do Servidor 1, a porta 80 (e qualquer outra porta que o Servidor 2 esteja configurado para passar para a VM) aparecerá como Filtrada. No entanto, se eu fizer o mesmo nmap de qualquer outra máquina, as portas aparecerão como Open.
Eu sei que esta pergunta pode ser difícil de seguir, e eu certamente não espero que alguém que não seja prático simplesmente invente a resposta na hora. Mas eu me pergunto se alguém pode responder ... o que pode ser uma razão pela qual VM # 1 obtém os pacotes SYN do servidor # 1, mas não tenta enviar um SYN-ACK de volta? Eu pensei que o problema pode ter sido relacionado à máquina host, mas os SYNs claramente chegam à VM, apenas parece ignorá-los quando chegam lá - mas imediatamente responde a um SYN de qualquer outro cliente.
Apenas procurando por pistas aqui.
EDIT # 2: Seguindo as sugestões do kubanskamac, eu posso ter encontrado o problema.
Na VM # 1, o netstat -rn oferece:
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth0
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
Então, se eu estou lendo isso corretamente, qualquer coisa que a VM tenha destinado para 10.xxx NÃO vai para 192.168.0.1 (o adaptador do host VMWare, e o único caminho que a VM # 1 tem para o mundo externo).
Então, como faço a VM nº 1 pelo menos rotear pacotes destinados a 10.0.1.x através do gateway 192.168.0.1? Olhando para o netstat -rn do servidor # 2, parece-me que ele encaminharia o pacote adequadamente se o recebesse.
EDIT # 3: RESOLVIDO!
As pistas da edição # 2 estavam certas. Eu respondi minha própria pergunta usando o comando "route":
route add -net 10.0.2.0 máscara de rede 255.255.255.0 gw 192.168.0.1
Última pergunta: como faço o comando acima permanente?