Шлюз высокой доступности на pfSense.



  • Здравствуйте!
    Уважаемые форумчане, помогите разрешить следующую задачу. Необходимо с текущей конфигурации перейти на pfSense.

    На данный момент есть сеть, показанная на картинке (схема несколько упрощена по сравнению с действительностью).
    Main Router (r01) - это сервер с FreeBSD, который занимается фаерволингом и маршрутизацией. SW1 - коммутатор, в который приходят линки от двух провайдеров и к нему же

    подключены сервера. Сервера имеют по одному физическому сетевому интерфейсу.
    На R01 (на ip 91.91.91.254) провайдер статически смаршрутизировал два блоки из 125 белых адресов. R02 имеет один внешний IP и один внутренний. На R01 поднято около

    сотни (100) VLANов, схема - VLAN на абонента. На картинке приведен пример VLANов с белыми и серыми IP-адресами. Серые адреса отначиваются через ipfw. Белые выходят

    спокойно, пройдя через небольшой набор правил (netbios block, pipes, etc).

    Отказоустойчивость.

    На R01 есть скрипт, который мониторит шлюз провайдера и некоторые постоянно доступные адреса в сети Интернет (гуглоднс, яндекс, мэйл, вввру итп). Если скрипт решает,

    что канал через основного провайдера (ISP1) упал, то делает в качестве defaultgateway ip-адрес r02, а r02, в свою очередь, отначивает всё что через него идет, т.е. и

    белые и серые айпи.

    Самая сложная задача - это настроить backup-router. На данный момент имеется полурабочая схема, а именно: порт коммутатора, к которому подключен backup-router настроен

    идентично как порт main-router'a. На bakup-routerе поднят vlan, по которому пингом мониторится main-router и rsync'oм синхронизируются конфиги. В случае недоступности

    Main-router'а, backup "делает себя основным", меняет свой rc.conf на rc.conf main-router'a, меняет rc.firewall, итп. Запускает сервисы (dns, dhcp, etc…).
    Схема полурабочая, т.к. нет нормального перюключения обратно на main-router, приходиться вмешиваться вручную.

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

    Почему нужен переход на pfSense.
    В силу недостатка времени на администрирование FreeBSD, требуется интерфейс для быстрого и правльного выполнения задач, в котором будут структурированы и продуманы

    возможности выполнения различных задач по настройке роутера. Сейчас на серверах куча костылей, которые надоели, pfSense будет ограничивать в их создании.

    Подскажите пожалуйста, как можно реализовать схему отказоустойчивого шлюза на pfSense? Понятно, что у провайдеров можно выпросить ещё по два айпишника и настроить CARP

    на WAN интерфейсе, можно настроить CARP на серых айпи адресах. Но на счет белых IP-адресов из /30 подсети вопрос для меня остается открытым. От Vlan'ов отказываться

    нельзя, так-как абоненты не должны видеть друг друга.

    Буду благодарен за любую наводку на решение этого вопроса.



  • Эээ, а просто один pfsense с несколькими WAN не подойдет (Failover)? У вас же оба роутера в одной сети находятся?



  • Роутеры можно запихнуть в любую сеть. Необходимо именно наличие второго роутера, который будет брать на себя роль MASTERa в случае недоступности первого. На данный момент R02 всего навсего позволяет выходить в интернет через второго провайдера.



  • Так в чем основной вопрос-то? На /30 сети CARP настроить не выйдет. На серых адресах - да, настроить можно, поставив между pfSense'ми и провайдером небольшую железку с NAT. VLAN'ы pfSense умеет.
    ?



  • Вопрос - каким образом можно реализовать высокую доступность шлюза для /30 сетей?

    @rubic:

    На серых адресах - да, настроить можно, поставив между pfSense'ми и провайдером небольшую железку с NAT.

    Зачем? NAT можно поднять на pfSens'ах.  Если эта железка будет одна, то это очередное узкое место сети.



  • Я имею ввиду серые адреса на WAN'ах pfSense'ов (ведь белых для CARP вам явно не хватает). Вот и как вариант дабл-NAT с дополнительной железякой.
    Впрочем CARP можно настроить и с тем, что сейчас вам дает провайдер (т.е. с одним белым IP), но с некоторыми ограничениями в управляемости.
    Кратко, не давать WAN'ам pfSense'ов адресов (тип None), а единственный белый IP сделать виртуальным типа CARP. При этом извне вы сможете подключиться только к тому pfSense, который в данный момент является мастером.



  • "Note that the CARP addresses are virtual addresses. Unless you have console access to all machines in your CARP group, you will almost always want to assign an IP address to the physical interfaces. With a unique IP address for each of the physical interfaces, you will be able to communicate with the host and be absolutely sure with which machine you are interacting. Without IP addresses assigned to physical interfaces, you could find yourself with a setup where the backup gateways are unable to communicate (except with hosts in networks where the physical interfaces have addresses assigned), until they become the master in the redundancy group and take over the virtual IP addresses."
    Book of PF. 2nd Edition



  • Поправочка)) На чистом PF можно, но pfSense не даст: "The interface upon which the CARP IP resides must already have another IP defined directly on the interface (VLAN, LAN, WAN, OPT) before it can be utilized."



  • Да, к сожалению не получается. Когда убираешь IP на WAN  интерфейсе, CARP говорит, что нету ИП-адреса. А если бы получилось, то такой-же трюк удался бы с /30 подсетью.



  • А если поднять два хоста на том же Proxmox , создать из них кластер в режиме HA и уже в кластере поднять pfsense?
    В случае падения первого хоста - второй возьмет на себя его роль.



  • Не рассматривал такое решение, но почему бы и нет.
    Правильно ли я понимаю, что это будет некое облако, у которого будет видимость как у оного физического сервера? И таким образом мы одержим победу над /30 сетью?!



  • Если вам подходит вариант 2-ух идентичных ВМ с pfsense на борту, то - да. Но и хосты должны быть максимально идентичными - как минимум - CPU, motherboard. Т.е. будет ВМ с pfsense и двумя WAN на борту (failover), работающая в кластере. В вашей схеме кластер займет место в районе SW1.

    P.s. http://pve.proxmox.com/wiki/Proxmox_VE_Cluster , http://pve.proxmox.com/wiki/High_Availability_Cluster



  • Вот в идентичности будет проблема. Дело в том, что Main-router это сервер HP, а backup - это компик собранный на коленке.
    Может действительно правильное решение будет искать подходящий софт для облака, а внутри поднимать pfSense.