Estou tendo um problema com um servidor Ubuntu executando duas NICs em duas sub-redes diferentes e roteamento entre elas. Estamos executando um servidor Nginx como proxy reverso com uma sub-rede pública e uma sub-rede privada.
Estamos executando o servidor Ubuntu 15.04.
Aqui está a configuração:
eth0 Link encap:Ethernet HWaddr 00:50:56:88:6e:91
inet addr:89.21.20.14 Bcast:89.21.20.255 Mask:255.255.255.0
inet6 addr: fe80::250:56ff:fe88:6e91/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:89152 errors:0 dropped:0 overruns:0 frame:0
TX packets:1729 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5552124 (5.5 MB) TX bytes:286442 (286.4 KB)
eth1 Link encap:Ethernet HWaddr 00:50:56:88:16:0b
inet addr:10.150.200.50 Bcast:10.150.200.255 Mask:255.255.255.0
inet6 addr: fe80::250:56ff:fe88:160b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:549 errors:0 dropped:0 overruns:0 frame:0
TX packets:22 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:53395 (53.3 KB) TX bytes:1908 (1.9 KB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:160 errors:0 dropped:0 overruns:0 frame:0
TX packets:160 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:12960 (12.9 KB) TX bytes:12960 (12.9 KB)
Eu tenho o gateway na eth0.
Quando tento executar ping em 89.21.20.14 de um servidor na sub-rede 10.150.200.xx, ele não funciona e não consigo me comunicar com ele. O tráfego está atingindo a eth0, como posso ver
sudo tcpdump -i eth0 proto \\icmp
Eu também tentei fazer a mesma coisa indo de um servidor em 89.21.20.xx e acessando/ping 10.150.200.50, mas isso também não está acontecendo. Ao executar o tcpdump, posso ver os pings atingindo a eth1
O problema é que temos sites em execução nos servidores web da sub-rede privada e eles fazem referência a domínios que apontam para os IPs públicos em 89.21.20.xx e, portanto, não podem se comunicar com os sites/aplicativos.
Estou pensando que é algum tipo de problema de roteamento, mas não tenho certeza por onde começar.
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 89.21.24.1 0.0.0.0 UG 0 0 0 eth0
10.150.200.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
89.21.20.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 89.21.20.1 0.0.0.0 UG 0 0 0 eth0
10.150.200.0 * 255.255.255.0 U 0 0 0 eth1
localnet * 255.255.255.0 U 0 0 0 eth0
Responder1
Você declara nos comentários que não deseja a passagem de sub-rede. Você já pegou isso então, de não conseguir acessar eth0e eth1vice-versa, então seu problema já está resolvido.
Porém, se você tiver alguma outra dúvida, precisará ser mais específico com o que está perguntando. (O proxy reverso acontece de forma transparente, você não conseguirá acessar eth0ou eth1vice-versa, não sem passar nginxpelo servidor proxy reverso).
O texto abaixo é mantido por razões históricas.
Estou curioso para saber por que isso está marcadonginx, porque este não é um problema do NGINX, é o caso de você tentar ir de dentro ( eth1e da sub-rede interna) para fora ( eth0e da Internet pública) sem um roteador (ou um sistema configurado como roteador) instalado ou um regra para permitir que seu 'servidor' atue como um proxy de dentro para fora (que NÃO é um proxy reverso).
NGINX não é um proxy ou roteador. Um proxy reverso dirá “OK, então envie esta solicitação para o back-end, abc”. Em seguida, dirá "ABC: Envie-me a resposta", que enviará a solicitação inicial feita de fora para o servidor interno. Isso fornece a resposta do back-end 'abc' no servidor nginx. Isso é retornado pelo nginx ao cliente solicitante.
Um proxy reverso também funciona apenas fora -> dentro. Este diagrama mostra basicamente como isso parece visto de fora:
O caminho reverso funciona, mas apenas porque o sistema de proxy reverso (nginx) está aguardando a resposta dos back-ends e, em seguida, devolve esses dados ao navegador da Web ou ao cliente remoto que faz a solicitação de informações e espera uma resposta.
O caminho inverso, no entanto, NÃO permite que você passe eth1do proxy reverso para eth0o proxy reverso através do sistema proxy remoto - não é assim que o roteamento IP funciona e, para alcançar o que você deseja, você precisa de umrealroteador instalado que pode lidar com a travessia de rede dos IPs internos para o exterior e, em seguida, de volta para o endereço IP público eth0na caixa de proxy reverso, então ficaria assim:
A passagem de dados aqui, então, seria das caixas internas, através da caixa do roteador à qual estão conectadas, para a Internet e, em seguida, da Internet de volta para a sua eth0caixa. (A maneira mais básica de explicar isso, é claro).
No entanto, sua caixa de proxy reverso nãonãofunciona como um roteador, então não funciona da maneira que você pensa.
Em outra nota:
Você não consegue fazer ping de interno (que vai para eth1) para eth0diretamente, que está em umsub-rede completamente diferentea menos que você passe por um roteador real, saia e entre novamente. A menos que você configure seu servidor que também possui nginx para ser um roteador, o que pelos seus comentários parece não ser o caso. Portanto, isso "não é possível fazer ping entre interfaces e sub-redes" écomportamento esperado.