Как запустить сервер на виртуальной машине с единственным адресом DMZ

Собственно, это решение для моей задачи. Задача на самом деле простая, но для меня оказалось не так прямолинейно. Есть современный IBM сервер, на который не ставился коробочный продукт на основе RedHat4 (и сам RedHat4 не ставится, по крайней мере без применения бубна). Продукт ставится в виртуальной машине, но адрес DMZ всего один, поэтому простой вариант настройки (через бридж) не подходит. Сейчас реальный ip назначен хостовой машине, а в виртуальную машину через nat проброшены с хостовой машины только те порты, которые нужны. [тут место для всех спецов, которые будут ржать надо мной как лошади, а лично у меня сегодня это всё случилось впервые]На начало этого мракобесического эксперимента у меня была настроенная машина, на которой хост машина имела внятный адрес и через bridge осмысленный адрес имела нужная мне виртуальная машина. Я поинтересовался как првильно засунуть машину с двумя адресами в имеющийся у меня единственный адрес DMZ (вот тут — это та же ссылка, что и в начале поста). Мне ответили, что реальный ip надо хосту, а в виртуальную пробросить порты. Чем я и начал заниматься.

1) Первым делом надо было добавить виртуальную сеть для моих виртуальных машин.
Устанавливая конфигурацию с бриджем по какой-то инструкции, я выполнил пункт «А если есть там какая-то сеть, то её лучше удалить». И я её удалил. Разумеется, при создании новой виртуальной машины (или удаления и создания нового сетевого адаптера в существующей машине) у меня не выбирались никакие варианты, кроме bridge0, а мне-то как раз нужен был NAT. С этой целью сеть надо восстановить вот в таком виде:

[root@cent407 ~]# virsh net-list
Имя Статус Автозапуск
—————————————-
default активен yes

Дело в том, что ни гуй, ни консоль не дают явной возможности создания виртуальной сети. Её можно только импортировать из файла xml. И я очень долго искал описание что за XML должен быть. Вот он:

[root@cent407 ~]# cat /etc/libvirt/qemu/networks/default.xml
<network>
<name>default</name>
<uuid>c421462c-0468-f2a4-a9cc-373e93a2cdba</uuid>
<forward mode=’nat’/>
<bridge name=’virbr0′ stp=’on’ delay=’0′ />
<ip address=’10.0.0.2′ netmask=’255.255.255.0′>
<dhcp>
<range start=’10.0.0.5′ end=’10.0.0.254′ />
</dhcp>
</ip>
</network>

Вот тут проявите бдительность! Тут есть строка uuid, которую надо просто тупо удалить. Её при определении сети система впишет сама. После того, как вышеупомянутый XML будет помещён в файл /etc/libvirt/qemu/networks/default.xml, а uuid удалён, команды такие:

virsh net-define /etc/libvirt/qemu/networks/default.xml
virsh net-start default
virsh net-autostart default

После этого виртуальная сеть появляется.
Что бы было понятно по параметрам объявленной нами сети: создаётся сегмент сети. Хост машина «вотукнута» в неё адресом 10.0.0.2, начиная с 10.0.0.5 в витртуальной сети выдаются адреса через dhcp. А моя софтина по документации сама становится на адрес 10.0.0.1, поэтому то я так и определил остальные цифры. По дефолту CentOS разруливает настройки так, что бы интернет на виртуальных машинах был. Такой же, как на хостовой машине, разумеется.

2) Переносим наши виртуальные машины в созданную виртуальную сеть.
После того, как виртуальная сеть появилась, я не стал кропотливо изучать документацию на замену сетевого интерфейса, а малодушно запустил гуй на хостовой машине и в графическом менеджере виртуальных машин для каждой виртуальной машины вынес существующий интерфейс и поставил новый, но уже типа NAT, находящийся в нашей свежесозданной виртуальной сети. И снова интернет у всех машин есть, две машины в виртуальной сети видят друг друга, а вопрос только в том, что бы на эти виртуальные машины перенаправлялись порты хост сервера.

3) Переносим порт родной порт ssh на другое место. В порядке развлечения.
По сути моя конфигурация будет вот такой:

Интернет видит хост машину, а хост машина перенаправляет порт на виртуальную машину. Это перенаправление делается при помощи механизма iptables. Я в этом механизме совсем запутался и у меня голова пошла кругом. Я распечатал себе учебник и долгой осенней ночью читал его как захватывающий детектив. Прочитал. Стало понятнее, но не так, что бы всё понятно. В понимании ещё помогли не осиленные мною руководства: описание настройки iptables для виртуальных машин XEN и KVM (из которого выдрана картинка) и Пошаговое конфигурирование iptables (которое создано на основе уже распечатанного мною учебника). И ещё вот такое изложение.
Для того, что бы прорваться сквозь лес команд, я начал с простого: я попытался перенести порт хост машины на 8022, а порт 22 хостовой машины перенаправить на порт 22 виртуального сервера.
Сначала всё просто: в файле vim /etc/ssh/sshd_config раскомменчиваем слово Port и устанавливаем значение в 8022, выполняем service sshd restart и… и ничего не работает!
И тут я как бы вспоминаю, что я тут не для мебели сижу, а что я iptables настраиваю. И CentOS это вам не Debian, тут вообще всё что возможно по умолчанию закрыто напрочь. Мне надо получить вот такие настройки:

[root@cent407 ~]# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp — 0.0.0.0/0 0.0.0.0/0 udp dpt:53
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
ACCEPT udp — 0.0.0.0/0 0.0.0.0/0 udp dpt:67
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:67
ACCEPT all — 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTAB
LISHED
ACCEPT icmp — 0.0.0.0/0 0.0.0.0/0
ACCEPT all — 0.0.0.0/0 0.0.0.0/0
ACCEPT tcp — 0.0.0.0/0 172.16.1.4 tcp dpt:8022
REJECT all — 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited

Ну точнее, я уже понимаю, что не совсем такие — потому что это сейчас у компа такой адрес, а потом он будет DMZ, да и вообще нет смысла к этому привязываться, так как не было к этому привязано удалённое мною правило приёма порта 22.
Самое сложное в понимании этих таблиц то, что эти таблицы выполняются по очереди. И строчки у них идут последовательно. Можно добавить триста раз умную команду, но если она добавится в конец — после команды, которая «будет всё отвергать!» (с), то ничем она не поможет. Поэтому примеры из учебников вида iptables -A INPUT бла-бла-бла оперативно меняются на iptables -I INPUT 1 бла-бла-бла. Ну и удалять внесённые правила я тоже научился.
Сейчас я поправил строчку, что бы не было привязки к адресу:

# iptables -I INPUT 8 -p tcp —dport 8022 -j ACCEPT
# iptables -D INPUT 9

Локальный ssh работает. Сейчас займёмся более глобальным. Для того, что бы понять как и где гуляет наше входящее соединение, надо вести пальцем по таблице из учебника. Например, первая позиция. Смотрим куда оно попадает:

[root@cent407 ~]# iptables -L -n -t mangle
Chain PREROUTING (policy ACCEPT)
target prot opt source destination

Chain INPUT (policy ACCEPT)
target prot opt source destination

Всё хорошо: правил нет, а по умолчанию оно принимает пакеты. Вторая строка таблицы:

[root@cent407 ~]# iptables -L -n -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT tcp — 0.0.0.0/0 172.16.1.4 tcp dpt:22 to:10.0.
0.1

Chain POSTROUTING (policy ACCEPT)

Меняю на вариант без привязки к хосту:

[root@cent407 ~]# iptables -t nat -I PREROUTING 1 -p tcp —dport 22 -j DNAT —to-destination 10.0.0.1
[root@cent407 ~]# iptables -t nat -D PREROUTING 2
[root@cent407 ~]# iptables -L -n -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 to:10.0.
0.1

Chain POSTROUTING (policy ACCEPT)

Ну и последняя строчка, стоящая на пути между мной и перенаправленным портом — строка с таблицей filter:

[root@cent407 ~]# iptables -L -n -t filter
Chain INPUT (policy ACCEPT)

Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all — 0.0.0.0/0 10.0.0.0/24 state RELATED,ESTABLISHED
ACCEPT tcp — 0.0.0.0/0 10.0.0.1 tcp dpt:22
ACCEPT all — 10.0.0.0/24 0.0.0.0/0

Задаётся она вот так:

[root@cent407 ~]# iptables -t filter -I FORWARD 2 -p tcp —dst 10.0.0.1 —dport 22 -j ACCEPT

И после этого у меня работает перенаправление.

Завтра или ночью из дома буду баловаться во все остальные пернаправления. И у меня всё получится. А кто пришел просто поржать — ржите на здоровье!

Добавить комментарий

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.