Duas NICs e roteamento entre as interfaces

Question

Estou tendo um problema com um servidor Ubuntu executando duas placas de rede em duas sub-redes diferentes e navegando entre elas. Estamos executando um servidor Nginx como um proxy reverso com uma sub-rede pública e sub-rede privada.

Estamos executando o servidor Ubuntu 12.04.

Veja 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 em eth0.

Quando eu tento fazer o ping 89.21.20.14 de um servidor na sub-rede 10.150.200.xx, ele não está funcionando e não consigo me comunicar com ele. O tráfego está atingindo a eth0, como posso ver em

sudo tcpdump -i eth0 proto \icmp

Eu também tentei fazer o mesmo com um servidor em 89.21.20.xx e acessar / ping 10.150.200.50, mas isso também não está acontecendo. Ao executar o tcpdump eu posso ver os pings acertando eth1

O problema é que temos sites em execução nos servidores Web de 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 a pensar que é algum tipo de problema de encaminhamento, mas não tenho a certeza de 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

    

Answer 1

Você afirma nos comentários que não deseja a passagem de sub-redes. Você já tem isso, então, com a impossibilidade de alcançar eth0 de eth1 e vice-versa, então seu problema já está resolvido.

Se você tiver alguma outra pergunta, precisa ser mais específico com o que está perguntando. (O proxy reverso acontece de forma transparente, você não será capaz de alcançar eth0 de eth1 ou vice-versa, não sem passar por nginx no servidor proxy reverso).

% bl0ck_qu0te%

Estou curioso para saber por que isso é marcado nginx , porque esse é não é um problema do NGINX, é um caso de você tentar ir de dentro ( eth1 e a sub-rede interna) para fora ( eth0 e a Internet pública) sem um roteador (ou um sistema configurado como um roteador) ou uma regra para permitir que seu 'servidor' aja como um proxy de dentro de > out (que NÃO é um proxy reverso).

O NGINX não é um proxy ou roteador. Um proxy reverso dirá "OK, então envie este pedido para o backend, abc". Então, ele dirá "ABC: Envie-me a resposta", que enviará a solicitação inicial feita de fora para o servidor interno. Isso, então, você recebe a resposta do backend 'abc' no servidor nginx. Isso é retornado pelo nginx para o cliente solicitante.

Um proxy reverso também funciona apenas fora - > Este diagrama mostra basicamente como isso é visto de fora:

Ocaminhoinversofunciona,masapenasporqueoSistemadeProxyReverso(nginx)estáaguardandorespostadosback-endse,emseguida,retornaessesdadosaoNavegadordaWebouclienteremotosolicitandoinformaçõeseesperandoumarespostadevolta.

Ocaminhoinverso,noentanto,NÃOpermitequevocêvádeeth1noproxyreversoparaeth0noproxyreversoatravésdosistemaRemoteProxy-nãoéassimqueoroteamentoIPfuncionaeparaalcançaroquevocêSevocêquiseralcançar,precisarádeumroteadorrealquepossamanipularapassagemderededosIPsinternosparaoexterioreretornaraoendereçoIPpúblicodeeth0nacaixadeproxyreverso.entãoficariaassim:

Apassagemdedadosaqui,então,seriadascaixasinternas,dacaixadoroteadoràqualestãoconectadas,daInternetedepoisdaInternetdevoltaàsuacaixaeth0.(Amaneiramaisbásicadeexplicarissoéclaro).

Noentanto,asuacaixadeProxyReversonãoéduplicadacomoumrouter,peloquenãofuncionadaformacomopensa.

Emoutranota:

Vocênãoconseguefazerpingdeinterno(quevaiparaeth1)paraeth0diretamente,queestáemumasub-redecompletamentediferente,amenosquevocêváatravésdeumroteadorrealeirparafora,emseguida,devoltadentroAmenosquevocêconfigureoseuservidorquetambémtemnginxparaserumroteador,quedeseuscomentáriosparecenãoserocaso.Portanto,isso"não é possível efetuar ping entre interfaces e sub-redes" é o comportamento esperado .