Tengo un problema con un servidor Ubuntu que ejecuta dos NIC en dos subredes diferentes y realiza rutas entre ellas. Estamos ejecutando un servidor Nginx como proxy inverso con una subred pública y una subred privada.
Estamos ejecutando el servidor ubuntu 15.04.
Aquí está la configuración:
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)
Tengo la puerta de enlace en eth0.
Cuando intento hacer ping a 89.21.20.14 desde un servidor en la subred 10.150.200.xx, no funciona y no puedo comunicarme con él. El tráfico está llegando a eth0 como puedo ver en
sudo tcpdump -i eth0 proto \\icmp
También intenté hacer lo mismo desde un servidor en 89.21.20.xx y acceder/ping 10.150.200.50, pero tampoco funcionó. Al ejecutar tcpdump puedo ver los pings que llegan a eth1
El problema es que tenemos sitios web que se ejecutan en servidores web de subred privados y hacen referencia a dominios que apuntan a las IP públicas en 89.21.20.xx y, por lo tanto, no pueden comunicarse con los sitios/aplicaciones.
Estoy pensando que es algún tipo de problema de enrutamiento pero no estoy muy seguro de por dónde empezar.
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
Respuesta1
En los comentarios usted indica que no desea atravesar la subred. Entonces ya tienes esto de no poder comunicarte eth0desde eth1y viceversa, por lo que tu problema ya está resuelto.
Sin embargo, si tienes alguna otra pregunta, debes ser más específico con lo que preguntas. (El proxy inverso se realiza de forma transparente, no podrá acceder eth0desde eth1o viceversa, no sin pasar nginxpor el servidor proxy inverso).
Lo siguiente se conserva por razones históricas.
Tengo curiosidad por saber por qué esto está etiquetado.nginx, debido a que esto no es un problema de NGINX, se trata de un caso en el que intentas ir desde adentro ( eth1y la subred interna) hacia afuera ( eth0y la Internet pública) sin un enrutador (o un sistema configurado como enrutador) en su lugar o un regla para permitir que su 'servidor' actúe como un proxy desde adentro->hacia afuera (que NO es un proxy inverso).
NGINX no es un proxy ni un enrutador. Un proxy inverso dirá "OK, envíe esta solicitud al backend, abc". Luego dirá "ABC: envíame la respuesta", lo que enviará la solicitud inicial realizada desde fuera al servidor interno. Luego obtendrá la respuesta del backend 'abc' en el servidor nginx. nginx lo devuelve al cliente solicitante.
Un proxy inverso también solo funciona afuera -> adentro. Este diagrama muestra básicamente cómo se ve desde afuera:
La ruta inversa funciona, pero solo porque el sistema de proxy inverso (nginx) está esperando la respuesta de los servidores y luego devuelve esos datos al navegador web o al cliente remoto que realiza la solicitud de información y espera una respuesta.
Sin embargo, la ruta inversa NO le permite pasar del eth1Proxy inverso al eth0Proxy inverso a través del sistema de Proxy remoto; así no es como funciona el enrutamiento IP y, para lograr lo que busca, necesita unrealenrutador instalado que puede manejar el cruce de la red desde las IP internas hacia el exterior y luego regresar a la dirección IP pública eth0en el cuadro de proxy inverso, por lo que se vería así:
El recorrido de datos aquí, entonces, sería desde las cajas internas, a través de la caja del enrutador al que están conectados, a Internet y luego desde Internet de regreso a su eth0caja. (La forma más básica de explicar esto, por supuesto).
Sin embargo, su cuadro de proxy inverso nonofunciona como enrutador, por lo que no funciona de la manera que crees.
En otra nota:
No puedes hacer ping desde interno (que va a eth1) a eth0directamente, que está en unsubred completamente diferentea menos que pase por un enrutador real y salga y luego vuelva a entrar. A menos que configure su servidor que también tiene nginx para que sea un enrutador, lo cual, según sus comentarios, parece no ser el caso. Entonces, este "no poder hacer ping a través de interfaces y subredes" escomportamiento esperado.