Здравстуйте все! Вот такая сложилась ситуация.
Имеется интернет-шлюз на linux. Непосредственно на нем поднят виртуальный сервер под VirtualBox (тоже линукс). На виртуалке крутится HTTP-сервер (=www.my.site.ru=,apache), который слушает, допустим, на 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Все сайты нормально доступны как изнутри (LAN) так и снаружи (Internet).
Теперь из-под шлюза делаю так:
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". В логах файрвола как на реальной системе так и на виртуальной дропов нет. Пинги проходят нормально всегда.
Что пробовал.
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-сервером, или любым другим слушающим приложением под виртуалкой. Вопрос в том, почему именно с самого шлюза соединения не проходят, а изнутри и снаружи все нормально.
Вобщем, интересует как грамотно прописать перенаправление запросов с интернет-шлюза на виртуальную машину-сервер, работающую под этим же шлюзом.
>[оверквотинг удален]
> iptables -t nat -A OUTPUT -d 127.0.0.1 -p tcp --dport 80 -j
> DNAT --to-destination 192.168.2.10
> Результат тот же.
> На самом деле совершенно не принципиально к какому порту я пытаюсь подключиться.
> Вэб-сервер выбран только для примера. Тоже самое будет при соединении, например,
> с ssh-сервером или mail-сервером, или любым другим слушающим приложением под виртуалкой.
> Вопрос в том, почему именно с самого шлюза соединения не проходят,
> а изнутри и снаружи все нормально.
> Вобщем, интересует как грамотно прописать перенаправление запросов с интернет-шлюза на
> виртуальную машину-сервер, работающую под этим же шлюзом.правильно что не работает -- потому что маршрут идёт через lo, точнее через "ip ro sh table local"
для решенияф данной задачи проще всего сделать xinetd с redirect'ом и забыть про nat,pre/postrouting и forward.
НО, остаётся непонятным зачем искать проблему при её фактическом отсутствии.
>[оверквотинг удален]
>> с ssh-сервером или mail-сервером, или любым другим слушающим приложением под виртуалкой.
>> Вопрос в том, почему именно с самого шлюза соединения не проходят,
>> а изнутри и снаружи все нормально.
>> Вобщем, интересует как грамотно прописать перенаправление запросов с интернет-шлюза на
>> виртуальную машину-сервер, работающую под этим же шлюзом.
> правильно что не работает -- потому что маршрут идёт через lo, точнее
> через "ip ro sh table local"
> для решенияф данной задачи проще всего сделать xinetd с redirect'ом и забыть
> про nat,pre/postrouting и forward.
> НО, остаётся непонятным зачем искать проблему при её фактическом отсутствии.Значит xinetd. Спасибо! Пожалуй, я думал в том же направлении. Буду разбираться дальше.
> Значит xinetd. Спасибо! Пожалуй, я думал в том же направлении. Буду разбираться
> дальше.Все получилось! С 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).