Многофункциональный мост pfSense, NAT, балансировка нагрузки и CARP


9

контекст

У меня сейчас есть:

  • 1 маршрутизатор pfSense 2.0.2 (на Firebox X-Peak X5000)
  • 2 WAN
  • 1 локальная сеть
  • 3 сервера

Мои интерфейсы

  • WAN1 68.XX.XXX.98 до 69.XX.XXX.102
  • WAN2 65.XXX.XXX.58 до 66.XXX.XXX.62
  • LAN 192.168.1.XXX
  • ДМЗ

Мой роутер настроен так:

  • Балансировка нагрузки с группой шлюзов на основе этой документации .
  • NAT
  • Правила для серверов локальной сети
  • Мост между WAN2 и DMZ (с внешними IP-адресами на одном DMZ-сервере) - но не может обмениваться данными между этим сервером и другими серверами в локальной сети, проходя по внешнему IP-адресу. Благодаря настраиваемой конфигурации маршрута я смог обрабатывать запросы от локальной сети к серверу в DMZ, но мне не нравится делать это так.

Мои серверы используют локальные IP-адреса 192.168.1.XXX, так же как и для моих компьютеров.

Ожидая

Я хотел бы сделать две вещи:

1 Соедините две глобальные сети с DMZ и локальной сетью за NAT

Мне нужна возможность приписывать внешние IP-адреса серверам и возможность смешивать IP-адреса одного и того же сервера из обеих глобальных сетей. Я также хотел бы иметь возможность общаться с серверами из примера локальной сети:

192.168.1.100 <--> http://68.XX.XXX.99

Также возможность связи с сервером на другой пример сервера:

65.XXX.XXX.59 <--> http://68.XX.XXX.99
  • Нужно ли будет выделять один внешний IP-адрес для компьютеров в локальной сети за NAT?
  • Смогу ли я поддерживать балансировку нагрузки для NAT?

Примечание. Я хотел бы избежать индивидуального NAT, поскольку локальные IP-адреса на сервере усложняют настройку виртуального хостинга, поэтому я предпочитаю использовать внешние адреса.

2 Аппаратное резервирование маршрутизатора (CARP)

У меня есть еще один Firebox X-Peak X5000 идентичный, и я хотел бы поместить его в качестве резервной копии, если первый выйдет из строя, второй может вступить во владение без (или почти) потери сети (т. Е. Запросы извне на сервер должны работать, также из локальной сети и серверов в Интернет).

Я прочитал эту документацию , но я понятия не имею, может ли она работать с моей конфигурацией (Bridge + NAT + Load Balancing)

Ответы:


2

Это можно было бы довольно просто прояснить, используя один-к-одному (или статический) NAT. Ваши интерфейсы будут настроены так же, как и в настоящее время, с той лишь разницей, что вы не будете соединять интерфейсы WAN / DMZ.

Единственное, чего не добьется, - это разрешить вам говорить из адресного пространства локальной сети в ваше внешнее адресное пространство. Я предполагаю, что проблема, возможно, DNS-запрос возвращает внешний адрес? В этом случае вы можете изменить конфигурацию BIND, включив в нее два разных представления - внутреннее и внешнее - для обеспечения разных возвратов в зависимости от источника запроса DNS.

Я полагаю, что единственное другое решение - получить все, что вы просите здесь, - это дать обоим интернет-провайдерам назначить вам другой блок адресов, который вы будете использовать в своем интерфейсе DMZ.

Что касается бита аппаратного сбоя, он должен работать нормально, если ваши интерфейсы подключены в той же области L2, что и первый межсетевой экран. Похоже, что он активный / пассивный, так что все должно быть в порядке.


Что касается метода «один-к-одному», я бы хотел его избежать (следует включить его в свой вопрос), я также сомневаюсь, что у меня может быть 2 IP-блока на одного провайдера. Думаю, я мог бы создать 4 WANS, по 2 на каждого провайдера, по одному на каждого провайдера для DMZ и один для NAT, звучит хорошо?
Александр Лавуа

2

Для multi-wan bridge + NAT + балансировка нагрузки это можно настроить следующим образом:

1 Создайте интерфейс DMZ

  • Тип конфигурации IPv4: Нет

2 Создайте мост

  • Интерфейсы
  • Присвоить
  • Мосты
  • Добавить
  • Выберите WAN1, WAN2 и DMZ

3 Правила брандмауэра

Разблокируйте необходимые порты и разрешите их в соответствующей глобальной сети:

  • Источник : *
  • Порт: *
  • Назначение: внешний IP-адрес

С такой конфигурацией серверы в DMZ теперь могут работать с публичными IP-адресами. Пока единственным недостатком является то, что я не могу получить доступ к хостам на DMZ из локальной сети.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.