Как разрешить повару прослушивать несколько IP-адресов
Сейчас я играю с шеф-поваром, чтобы оценить, может ли такой инструмент настройки помочь нам в нашей среде на основе * 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-сервер.
Насколько я понимаю, 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 недели, поэтому я ожидайте, не существует "простого" способа достижения цели.
Я хочу поделиться своими идеями о том, как выглядит мой "обходной путь". Может быть, это поможет тем, кто сталкивается с подобной проблемой.
- Подсеть A: 192.168.1.0/24
- Подсеть B: 192.168.2.0/24
- Подсеть C: 192.168.3.0/24
Я добавил новую, отдельную подсеть (C), которая похожа на dmz (из-за содержимого нет, но я надеюсь, что вы уловили идею). Впоследствии я создал политики для shorewall, которые разрешают маршрутизацию из подсети A и B во вновь созданный C, но не в обратном направлении. Таким образом, шеф-клиенты из обеих сетей, A и B, могут подключаться к шеф-серверу в C, но A и B по-прежнему не могут общаться друг с другом. Кроме того, C не разрешено связываться с системами, находящимися за A и B, поэтому даже если кто-то захватит A или B, у него все равно будут проблемы с доступом к другим подсетям. Хотя это немного усложнит добавление новых узлов, это все еще довольно просто (например, написать общий скрипт, устанавливающий chef-client и соединяющий его с сервером или используя локальную версию 'Knife').
Вот ( упрощенный) файл политики, который в настоящее время используется 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).