iptables/SuSEfirewall

Имеется шлюз на SUSE-linux. Непосредственно на нем поднят виртуальный сервер под VirtualBox (тоже линукс). На виртуалке крутится HTTP-сервер (=www.my.site.ru=), который слушает, допустим, на 192.168.2.10. Внешний адрес шлюза пусть будет 111.222.333.444, а внутренний 192.168.0.2. Виртуалка подключена к сети с помощью хост-адаптера виртуальной машины (vboxnet0) с адресом 192.168.2.1 (он же шлюз для гостевой системы). Виртуальный интерфейс помещен в демилитаризованную зону файрвола (dmz).


Для удобства все параметры сведу воедино:

linux: openSUSE 11.4 (kernel 2.6.37.6-24)
gate ext ip: 111.222.333.444
gate int ip: 192.168.0.2
virtual server ext ip: 192.168.2.10
virtual host-adapter ip: 192.168.2.1
domain name: =www.my.site.ru=

В iptables шлюза прописано:

iptables -t nat -A PREROUTING -d 111.222.333.444 -p tcp --dport 80 -j DNAT --to-destination 192.168.2.10
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p tcp --dport 80 -d 192.168.2.10 -j ACCEPT

Все сайты нормально доступны как изнутри так и снаружи.

Теперь из-под шлюза делаю так:

telnet my.site.ru 80

Шлюз выдает ответ:

Trying 111.222.333.444...
telnet: connect to address 111.222.333.444: Connection refused

Делаю тоже самое с любой машины из локальной сети:

Trying 111.222.333.444...
Connected to 111.222.333.444.
Escape character is '^]'.
Подключаюсь с любой машины снаружи:
Trying 111.222.333.444...
Connected to 111.222.333.444.
Escape character is '^]'.

Т.е. соединение устанавливается.

Когда пробую обратиться с шлюза непосредственно к ip виртуального сервера:

telnet 192.168.2.10 80
Trying 192.168.2.10...
Connected to 192.168.2.10.
Escape character is '^]'.

Тоже все нормально.

Т.о. перенаправление с внешнего ip-адреса шлюза под виртуалку происходит только с внешнего и внутреннего интерфейсов шлюза. Когда же я выполняю запрос из-под самого шлюза, выдается отказ в доступе, как будто перенаправления нет, и соединение идет непосредственно на порт локальной машины (который, естественно, закрыт и никто на нем не слушает). Правда, смущает сообщение "Connection refused". В логах файрвола как на реальной системе так и на виртуальной все чисто (даже с FW_LOG_DROP_ALL="yes"). Пинги проходят нормально всегда.

Что пробовал.
1. Пробовал открывать порт 80 на шлюзе (по идее iptables и так должен перенаправлять):

iptables -A INPUT -p tcp --dport 80 –j ACCEPT

2. Пробовал отключать файрвол вообще (плохая идея).
3. Пробовал вставлять правило в цепочку OUTPUT (ибо обращение локальное, имхо):

iptables -t nat -A OUTPUT -d 111.222.333.444 -p tcp --dport 80 -j DNAT --to-destination 192.168.2.10

Или так:

iptables -t nat -A OUTPUT -d 192.168.0.2 -p tcp --dport 80 -j DNAT --to-destination 192.168.2.10

Или даже так:

iptables -t nat -A OUTPUT -d 127.0.0.1 -p tcp --dport 80 -j DNAT --to-destination 192.168.2.10

Результат тот же.

На самом деле совершенно не принципиально к какому порту я пытаюсь простучаться. Вэб-сервер выбран только для примера. Тоже самое будет если я соединюсь, например, с ssh-сервером или mail-сервером, или любым другим слушающем приложением под виртуалкой. Вопрос в том, почему именно с самого шлюза соединения не проходят, а изнутри и снаружи все работает.

Вобщем, интересует как грамотно прописать перенаправление запросов с интернет-шлюза на виртуальную машину, работающую под этим же шлюзом.

Вот тут и тут почитайте.
И попробуйте tcpdump'ом посмотреть приходять хоть какието пакеты на вашу виртуалку при обращении к ней из хост-системы.

Эти ссылки знаю.
Пакеты на виртуалку приходят, иначе, как бы я мог достучаться до сервака :) Но, если слушать именно при telnet'e, то dump будет пустой. В этом-то и дело, что пакеты адресованные серверу самим сервером не переадресовываются на виртуалку.

Я тут "раскинул" мозгами и вот что придумал. К тем настройка фаервола что у вас есть

...
iptables -t nat -A OUTPUT -d 111.222.333.444 -p tcp --dport 80 -j DNAT --to-destination 192.168.2.10

добавте такое правило

iptables -t nat -A POSTROUTING -p tcp --dst 192.168.2.10 --dport 80 -j SNAT 
--to-source 192.168.2.1

Не уверен что поможет, но попробывать можно. При условии что в сторону виртуалки смотрит айпи 192.168.2.1

"kisil" написал:

добавте такое правило

iptables -t nat -A POSTROUTING -p tcp --dst 192.168.2.10 --dport 80 -j SNAT
--to-source 192.168.2.1

Попробовал добавить - эффект тотже.

Все получилось! Надо было действовать через xinetd.
Отписываюсь по факту.

Добавил секцию в xinetd.conf:

service vm_telnet
{
type = UNLISTED
socket_type = stream
protocol = tcp
server = /usr/bin/telnet
user = root
wait = no
port = 80
only_from = 111.222.333.444
redirect = 192.168.2.10 80
}

Теперь пакеты, адресованные шлюзом самому себе на порт 80, свободно заворачиваются на виртуальный интерфейс на тотже порт. Таким же образом можно пробросить любой порт из-под шлюза на виртуалку.

НО, теперь самое главное!
В моем случае этого можно было не делать совсем. Достаточно было просто прописать имена хостов в файле hosts шлюза:

192.168.2.10 my.site.ru

Теперь шлюз считает, что my.site.ru это уже не 111.222.333.444, а 192.168.2.10. А, как я уже писал, на хост-интерфейс виртуальной машины пакеты идут совершенно свободно. Простое и элегантное решение, не требующее поднятия дополнительного сервиса Конечно, все это справедливо если обращаться к виртуалке по имени, а не по внешнему адресу шлюза 111.222.333.444. В моем случае, вариант с hosts меня полностью устраивает.

"Outloader" написал:

НО, теперь самое главное!
В моем случае этого можно было не делать совсем. Достаточно было просто прописать имена хостов в файле hosts шлюза:

192.168.2.10 my.site.ru