В настоящее время я играю с шеф-поваром, чтобы оценить, может ли такой инструмент настройки помочь нам в нашей среде на основе * nix.
Последние несколько дней я борюсь с одной проблемой, решения которой не могу найти. В принципе, у меня есть 2 диапазона частных сетей 192.168.1.0/24 и 192.168.2.0/24. Существует сервер (Ubuntu 14.04.4 LTS), имеющий доступ к обеим сетям (192.168.1.1/24 на em1 и 192.168.2.1/24 на em2), на котором запущен chef-сервер.
Насколько я понимаю, шеф-повар будет прослушивать интерфейс, для которого настроен маршрут по умолчанию (здесь 192.168.1.1 на em1). Однако я хочу, чтобы повар следил за серверами в обеих сетях.
Когда я загружаю серверы на 192.168.2.0/24, клиент устанавливается, но от клиента нет ответа, потому что сервер вызывает себя 192.168.1.1, который не отображается для 192.168.2.0/24 (в конце концов, это просто общая подсеть ).
Есть ли способ разрешить шеф-повару прослушивать оба интерфейса (например, что-то вроде "прослушать 0.0.0.0/0")? Я обыскал всю сеть, но нашел решения только для базовых сервисов, таких как книжная полка. У вас есть какие-либо советы, как реализовать управление конфигурацией в такой среде?
Привет Кеннет
Нет ответов через 2 недели, поэтому я полагаю, что не существует "простого" способа достижения цели.
Я хочу поделиться своими идеями о том, как выглядит мой «обходной путь». Может быть, это поможет тем, кто сталкивается с подобной проблемой.
Я добавил новую, отдельную подсеть (C), которая немного похожа на dmz (из-за содержимого ее нет, но я надеюсь, что вы уловите идею). Впоследствии я создал политики для shorewall, которые разрешают маршрутизацию из подсети A и B во вновь созданный C, но не в обратном направлении. Таким образом, шеф-клиенты из обеих сетей, A и B, могут подключаться к шеф-серверу в C, но A и B по-прежнему не могут общаться друг с другом. Кроме того, C не разрешено связываться с системами, находящимися за A и B, поэтому даже если кто-то захватит A или B, у него все равно будут проблемы с доступом к другим подсетям. Хотя это немного усложнит добавление новых узлов, это все равно довольно просто (например, написать общий сценарий, устанавливающий chef-client и подключив его к серверу, или используя локальную версию «ножа»).
Вот (упрощенный) файл политик, который в настоящее время использует shorewall:
#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
$FW A REJECT
$FW B REJECT
$FW C REJECT
A $FW DROP
A B REJECT
A C ACCEPT
B $FW DROP
B A REJECT
B C ACCEPT
C $FW DROP
C A REJECT
C B REJECT
# THE FOLLOWING POLICY MUST BE LAST
all all DROP info
В конце концов, это не то решение, которое я искал. Тем не менее, чем больше я думаю об этом, тем больше мне нравится это решение, потому что нет дополнительных мостов, кроме самого брандмауэра, и мы можем развертывать программное обеспечение, которое может быть полезно и в обеих подсетях (например, RabbitMQ).