Назад | Перейти на главную страницу

Веб-сервер недоступен для одной конкретной машины в том же центре обработки данных

Я программист, которого заставили выполнять обязанности администратора сервера, и у меня есть проблема, которая меня сильно смущает. Несомненно, виной всему недостаток знаний, так что научите меня, если можете. :)

ПРОБЛЕМА: два физических сервера, размещенных на одной и той же службе выделенного хостинга. Веб-сервер (работающий на виртуальной машине) на одном сервере не может быть доступен для другого сервера, но может быть доступен любому, кто пытается это сделать в Интернете.

НАСТРОИТЬ:

У нас есть два сервера, размещенных на ServerBeach. Оба работают под Debian, один под управлением VMWare Server 2 с двумя виртуальными машинами - на каждой также работает Debian. Каждая виртуальная машина работает под управлением Apache и обслуживает веб-сайт. Некоторые не настоящие IP для ясности:

СЕРВЕР №1 (eth0): 10.0.1.1
СЕРВЕР №2 (eth0): 11.0.0.1
Вторичный IP-адрес СЕРВЕРА №2 (eth0: 1) - для ВМ №1: 10.0.2.1
Вторичный IP-адрес СЕРВЕРА №2 (eth0: 2) - для ВМ №2: 10.0.2.2

Виртуальные машины на сервере №2 подключены к хосту через сеть только для хоста:
СЕРВЕР №2 (vmnet1): 192.168.0.1
ВМ № 1: 192.168.0.2
ВМ № 2: 192.168.0.3

... в то время как правила iptables на Сервере №2 берут Интернет-трафик, связанный с этими вторичными IP-адресами, и изменяют IP-адрес назначения для перехода к виртуальным машинам и обратно для трафика, идущего в Интернет с виртуальной машины:

-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

Это работает. Компьютер в Интернете может указать в своем браузере на http://10.0.2.1 и он запускает веб-сервер на виртуальной машине. Такая установка, при которой вторичные IP-адреса являются псевдонимами на хост-машине и не живут на самих виртуальных машинах, - вот как ServerBeach настаивает на настройке таких установок VMWare. И это делает свою работу.

Единственная странность заключается в том, что когда Сервер №1 пытается получить доступ к ВМ сервера №2, как и любой другой клиент в Интернете, время ожидания истекает. (Я вошел на сервер №1 через SSH и использую ссылки, чтобы попытаться перейти на сайт, или даже telnet на порт 80)

Если я запускаю tshark на виртуальной машине №1, я вижу, что пакеты SYN передаются с сервера №1 через сервер №2 на виртуальную машину:

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...)

Пакеты SYN продолжают поступать, но виртуальная машина никогда не отправляет обратно SYN-ACK.

Теперь, если я перейду на любой другой компьютер и перейду к этому URL-адресу в браузере, я увижу SYN, SYN-ACK и ACK и, конечно же, следующий трафик (мы назовем эту другую систему 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! ...)

То же самое происходит на виртуальной машине №2. Каждый может связаться с веб-сервером и связаться с ним Кроме Сервер №1.

Сервер №1, конечно, может подключиться к любому другому веб-сайту в Интернете.

РЕДАКТИРОВАТЬ: Если я запускаю nmap -sS 10.0.2.1 с Сервера №1, порт 80 (и любой другой порт, который Сервер №2 настроен на передачу виртуальной машине) отображается как Отфильтрованный. Однако, если я сделаю то же самое с любого другого компьютера, порты будут отображаться как «Открытые».

Я знаю, что этот вопрос может быть трудным для понимания, и я, конечно, не ожидаю, что кто-либо, кто не разбирается в практических вопросах, просто придумает ответ на месте. Но мне интересно, может ли кто-нибудь ответить ... в чем может быть причина, по которой виртуальная машина № 1 получает SYN-пакеты с сервера № 1, но НЕ пытается отправить обратно SYN-ACK? Я думал, что проблема могла быть связана с хост-машиной, но SYN явно попадают в виртуальную машину, просто кажется, что они игнорируют их, как только они попадают туда, но он сразу же отвечает на SYN от любого другого клиента.

Просто ищу здесь подсказки.

РЕДАКТИРОВАТЬ № 2: Следуя предложениям kubanskamac, я, возможно, нашел проблему.

На виртуальной машине №1 netstat -rn предлагает:

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

Итак, если я правильно это понимаю, все, что VM предназначила для 10.x.x.x, НЕ переходит на 192.168.0.1 (адаптер хоста VMWare и единственный путь VM № 1 к внешнему миру).

Итак, как мне сделать так, чтобы ВМ №1 по крайней мере маршрутизировала пакеты, предназначенные для 10.0.1.x, через шлюз 192.168.0.1? Глядя на netstat -rn Сервера №2, мне кажется, что он правильно маршрутизировал бы пакет, если бы получил его.

РЕДАКТИРОВАТЬ № 3: РЕШЕНО!

Подсказки Edit # 2 были правильными. Я ответил на свой вопрос с помощью команды "route":

route add -net 10.0.2.0 маска сети 255.255.255.0 gw 192.168.0.1

Последний вопрос: как сделать указанную выше команду постоянной?

Кажется, что Server1 находится в той же подсети, что и интерфейс eth0: 1 Server2, но вы не указали сетевые маски, поэтому я не уверен.

Правило POSTROUTING сработает только после того, как Server2 решит отправить пакет через eth0, eth0: 1 или eth0: 2. Чтобы отправить пакет, Server2 должен выяснить, какой MAC-адрес является желаемым местом назначения (он использует ARP для поиска MAC). Если Server1 находится в другой подсети, пакет должен быть отправлен на MAC-адрес шлюза по умолчанию. Если Server1 находится в той же IP-подсети (так выглядит), нет необходимости беспокоить шлюз по умолчанию, и только Server2 пытается разрешить IP-адрес на какой-либо используемый MAC. В случае неудачи пакет не может быть отправлен - ему некуда идти.

   arp -a        # (on Server2) print known MACs
   netstat -rn   # (on Server2 and VM1) print table for IP routing decisions

Вы знаете, что правильно доступен только 10.x.x.x, а не 11.x.x.x? Другие доступные IP-адреса: 172.16-32.x.x и 192.168.x.x. 170.x.x.x отсутствует. Вы упомянули, что предоставленные IP-адреса поддельные, поэтому это может не помочь.

Указан ли IP-адрес сервера №1 в файле /etc/hosts.deny виртуальной машины или ее хоста?

Я полагаю, вы проверили правила брандмауэра виртуальной машины, чтобы убедиться, что она не удаляется.

Ваш NAT мешает. В частности, возвращаемые пакеты имеют исходный адрес источника как dest и поэтому не проходят через устройство NAT для де-NAT.