Два NICs и направляющий между интерфейсами
У меня есть проблема с сервером Ubuntu, выполняющим два NICs на двух различных подсетях androuting между ними. Мы выполняем сервер Nginx как обратный прокси с общедоступной подсетью и частной подсетью.
Мы выполняем сервер человечности 15.04.
Вот установка:
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)
У меня есть шлюз на eth0.
Когда я пытаюсь проверить с помощью ping-запросов 89.21.20.14 с сервера на 10.150.200.xx подсеть, она не работает, и я не могу общаться с нею. Трафик поражает eth0, как я вижу от
sudo tcpdump -i eth0 proto \\icmp
Я также попытался сделать то же самое, идущее с сервера в 89.21.20.xx и доступ/ping 10.150.200.50, но это не проходит также. Когда выполнение tcpdump I видит, что ping поражают eth1
Проблема состоит в том, что у нас есть веб-сайты, работающие на частных веб-серверах подсети, и они ссылаются на домены, которые указывают на общедоступного дюйм/с на 89.21.20.xx и поэтому не могут общаться с сайтами/приложениями.
Я думаю, что это - некоторая проблема маршрутизации, но не слишком уверенное в том, где запустить?
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
1 ответ
Вы заявляете в комментариях, что Вы не хотите обход подсети. Вы уже получили это, затем, с неспособностью достигнуть eth0 от eth1 и наоборот, таким образом, Ваш вопрос уже решен.
Если у Вас есть некоторый другой вопрос, тем не менее, необходимо быть более конкретными с тем, что Вы спрашиваете. (Обратное проксирование происходит прозрачно, Вы не сможете достигнуть eth0 от eth1 или наоборот, не без прохождения через nginx на обратном прокси-сервере).
Ниже сохранен по историческим причинам.
Мне любопытно, почему это отмечено nginx, потому что это не проблема NGINX, это - случай Вас пытающийся пойти изнутри (eth1 и внутренняя подсеть) к внешней стороне (eth0, и общедоступный Интернет) без маршрутизатора (или система, настроенная как маршрутизатор) на месте или правило позволить Вашему 'серверу' действовать как прокси изнутри> (который НЕ является обратным прокси).
NGINX не является прокси или маршрутизатором. Обратный прокси скажет "хорошо, поэтому отправит этот запрос к бэкенду, abc". Затем это скажет "ABC: Отправьте мне ответ", который отправит начальный запрос, выполненный снаружи к внутреннему серверу. Это затем получает Вас ответ от бэкенда 'abc' в nginx сервере. Это возвращается nginx клиенту запроса.
Обратный прокси также только работает снаружи-> в. Эта схема показывает в основном, как это смотрит от внешнего входа:
Обратные работы пути, но только потому, что Обратная Система Прокси (nginx) ожидает ответа от бэкендов и затем возвращает те данные веб-браузеру или удаленному клиенту, делающему запрос информации и ожидающему ответ назад.
Обратный путь, однако, НЕ разрешает Вам идти от eth1 на Обратном Прокси к eth0 на Обратном Прокси через Удаленную систему Прокси - это не то, как маршрутизация IP работает, и достигнуть того, чего Вы надеетесь достигать, Вам нужен реальный маршрутизатор на месте, который может обработать сетевой обход от Внутреннего дюйм/с до внешней стороны, и затем обратно к Общедоступному IP-адресу eth0 на обратном поле прокси, таким образом, это было бы похоже на это:
Обход данных здесь, затем, был бы от внутренних полей через поле маршрутизатора, они подключены с, с Интернетом, и затем из Интернета назад к Вашему eth0 поле. (Самый основной способ объяснить это, конечно).
Однако Ваше поле Reverse Proxy не удваивается как маршрутизатор, таким образом, оно не работает в способе, которым Вы думаете, что оно делает.
На другой ноте:
Вы не добираетесь для проверки с помощью ping-запросов от внутреннего (который переходит в eth1) к eth0 непосредственно, который находится на совершенно другой подсети, если Вы не проходите реальный маршрутизатор и выходите на улицу затем обратно в. Если Вы не настраиваете свой сервер, который также имеет nginx на нем, чтобы быть маршрутизатором, который из Ваших комментариев, кажется, не имеет место. Так, это, которое "не в состоянии проверять с помощью ping-запросов через интерфейсы и подсети", является ожидаемым поведением.