На днях решил вопрос с мониторингом из офиса нескольких виртуальных машин, находящихся за NAT-ом удаленного сервера, с помощью Zenoss. На этом удаленном сервере установлена система Gentoo, и под ней также работают несколько гостевых KVM - машин. Почему раньше не получалось настроить мониторинг? Потому что Zenoss не умеет это делать: при добавлении в нем новых устройств воспринимаются только те, IP-адреса (или dns-имена, соответствующие этим IP-адресам) которых еще не отслеживаются, в противном случае выдает ошибку. В nagios или icinga такой проблемы нет: там, например, можно настроить мониторинг с помощью nrpe - команд для определенных сервисов, указав порт NAT-а, который осуществляет перенаправление на нужный порт нужного сервера. Хотя Zenoss тоже можно "обмануть" с помощью NAT-а, используя check_* команды, само устройство нельзя добавить через интерфейс программы, так как такой IP-адрес уже отслеживается и соответствует удаленному серверу с натроенным NAT.
Решение я нашел в интернете . Идея заключается в том, что берется любой IP-адрес из диапазона частных сетей, в фаерволе делаем перенаправление для этого адреса на нужный порт нашего удаленного NAT-сервера, а в Zenoss спокойно добавляем новое устройство с этим IP.
Здесь я описываю решение чуть подробнее и дополнительно объясняю возможность мониторинга в случае, когда Zenoss находится не на машине с NAT-ом, а за ней - на отдельном сервере. Моей задачей не является описание принципов работы мониторинга или фаервола - это слишком обширная тема, поэтому для понимания того, что описывается, надо быть с этими принципами знакомым.
Для начала вспомним, как выглядит алгоритм работы фаервола iptables ( картинка взята с сайта frozentux.net ):
Рассмотрим вариант, когда Zenoss находится на машине с NAT-ом. На диаграмме продвижение пакетов начинается с пиктограммы "Local Process". Обычно для работы DNAT/SNAT достаточно использования таблиц PREROUTING/POSTROUTING. В нашем случае для настройки напрашивается POSTROUTING, но она не работает с портом назначения IP-пакетов, поэтому воспользуемся таблицей OUTPUT ( на диаграмме это пиктограмма "nat OUTPUT" ).
На рисунках у меня используются IP-адреса из сети 10.0.0.0/8, но я намеренно использую ниже сеть 198.168.0.0/16, чтоб показать, что Zenoss можно "обмануть" любым IP-адресом. В примерах далее 10.3.0.3 будет соответствовать IP-адресу 192.168.1.3 устройства в Zenoss, а 10.3.0.2 - 192.168.1.2. Само собой разумеется, что IP-адреса из диапазона частных сетей ( интерфейсы if1 обоих NAT-ов ) используются мною только для примера - любой маршрутизатор в интернете подобные адреса заблокирует, так что в реальной жизни они у вас будут другими. Да, забыл сказать, что Zenoss у меня мониторит удаленные машины через ssh ( используется модуль zenplugin ), поэтому для опроса нужен 22-й порт.
iptables -A OUTPUT -t nat -d 192.168.1.3 -o if1 -p tcp --dport 22 -j DNAT --to-destination 10.0.2.1:3333
iptables -A OUTPUT -t nat -d 192.168.1.2 -o if1 -p tcp --dport 22 -j DNAT --to-destination 10.0.2.1:3334
То есть когда Zenoss будет опрашивать сервер по адресу 192.168.1.3, IP-пакеты будут автоматически перенаправляться на удаленный NAT-сервер 10.0.2.1, а уже на нем призойдет перенаправление через порт 3333 на порт 22 виртуального хоста с IP-адресом 10.3.0.3. Преобразований в таблице POSTROUTING не требуется.
Соответственно, на удаленном NAT - сервере ( эти три правила для обоих вариантов одинаковы ):
iptables -A PREROUTING -t nat -s 10.0.1.1 -d 10.0.2.1 -i if1 -p tcp --dport 3333 -j DNAT --to-destination 10.3.0.3:22
iptables -A PREROUTING -t nat -s 10.0.1.1 -d 10.0.2.1 -i if1 -p tcp --dport 3334 -j DNAT --to-destination 10.3.0.2:22
iptables -A POSTROUTING -t nat -s 10.3.0.0/29 -j SNAT --to-source 10.0.2.1
Теперь рассмотрим второй случай, когда Zenoss находится за двумя NAT-ми до опрашиваемых виртуальных машин:
IP-пакеты от Zenoss вначале попадают на сетевой интерфейс if2 офисного фаервола NAT1. Теперь нас интересует пиктограмма "nat PREROUTING" диаграммы. После применения правил в PREROUTING пакеты попадают в таблицу FORWARD ( "filter FORWARD" на диаграмме), где, как правило, уже разрешен форвардинг для машин локальной сети в интернет. Дальше в таблице POSTROUTING ( "nat POSTROUTING" на диаграмме ) изменяем адрес источника локальной сети на IP-адрес внешнего интерфейса, "глядящего" в интернет.
iptables -A PREROUTING -t nat -s 10.5.0.2 -d 192.168.1.3 -i if2 -p tcp --dport 22 -m comment --comment "zenoss checks Server1 behind NAT2" -j DNAT --to-destination 10.0.2.1:3333
iptables -A PREROUTING -t nat -s 10.5.0.2 -d 192.168.1.2 -i if2 -p tcp --dport 22 -m comment --comment "zenoss checks Server2 behind NAT2" -j DNAT --to-destination 10.0.2.1:3334
iptables -A POSTROUTING -s 10.5.0.0/24 -o if1 -j SNAT --to-source 10.0.1.1
Кстати, вы используете возможность комментировать правила iptables (модуль comment)? Последнее время я стараюсь это делать, поскольку появились длинные и не всегда очевидные цепочки правил, смысл которых спустя пол-года после их написания становится совершенно непонятным.
После добавления новых устройств с IP-адресами 192.168.1.3 и 192.168.1.2 в Zenoss можно получить графики загрузки процессора, памяти, диска и т.д. Я не рассматриваю здесь возможность опроса Zenoss-ом доступности виртуальных машин непосредственно с помощью snmp - мы ведь и так опрашиваем устройство NAT2? "Падением" Server1, Server2 можно считать недоступность порта 22 этих машин, о чем Zenoss сможет сообщить по электронной почте (смс...). В целом, предложенная товарищем идея мониторинга устройств за NAT достаточно проста, но неочевидна. Остаётся также надежда, что разработчики Zenoss решат данный вопрос в корне, и тогда не придётся изобретать велосипед с NAT-ом.
Комментариев нет:
Отправить комментарий