У меня два кластера pfSense, один - 2.1.4, а другой - 2.1.3.
В направления предположить, что NAT для исходящего трафика вручную требуется, но кластер 2.1.3 работает нормально, используя автоматический NAT, серверы и все остальное (включая SSH и OpenVPN).
Кластер 2.1.4 использует NAT для исходящего трафика вручную и вызывает проблемы. NAT имеет три автоматически добавляемых правила, обозначенных следующим образом:
Они также были созданы как для нашей внутренней сети (192.168.6.0/24), так и для нашей сети разработчиков (10.2.0.0/8). Есть два ручных правила:
Этот кластер брандмауэра был тестовым кластером - тогда основной был выделен для единого производственного брандмауэра системы - и теперь снова стал кластером ... и имеет ряд изменений IP-адресов.
Теперь все работает через NAT для адреса кластера, но OpenVPN по-прежнему использует основной адрес. Что мне не хватает? Должен ли я вернуться к автоматическому NAT? Если, с другой стороны, я переведу кластер 2.1.4 в режим ручного NAT (для обработки связи с вторичным сервером через VPN), возникнут ли у меня проблемы?
РЕДАКТИРОВАТЬ Я должен отметить, что все остальное, похоже, работает - включая SSH для адреса кластера, а исходящий HTTP показывает адрес кластера и так далее. SSH, конечно, порт 22, а OpenVPN - 1194 (больше 1024). Клиент OpenVPN работает (межсайтовый VPN). Кажется, это просто исходящий трафик с сервера OpenVPN на порт 1194, который не является NAT.
Я попытался запустить OpenVPN на порту 23 с соответствующими правилами брандмауэра - и он по-прежнему отправлял ответы с адреса WAN, а не с адреса кластера.
ОБНОВИТЬ Я упомянул, что было не так, но не совсем точно. Вот чего я ожидал:
Вот что я вижу:
Вы предложили проверить IP, к которому привязан сервер OpenVPN; был ЛЮБОЙ и изменился на IP-адрес кластера; еще не тестировал.
На самом деле проблема была намного проще, чем казалось. Сервер OpenVPN был настроен для прослушивания интерфейса любой; когда я изменил интерфейс на IP-адрес кластера, все начало работать. (Интерфейс - одно из выпадающих меню на вкладке конфигурации сервера OpenVPN.)
Это решило две возникшие проблемы.
Во-первых, он прослушивал «все» интерфейсы, но не IP-адрес кластера, поскольку он не был включен в его определение «все». Изменение интерфейса для прослушивания IP-адреса кластера заставило сервер прослушивать только этот интерфейс, но в любом случае это желаемое поведение.
Во-вторых, когда интерфейс указан как любой система не видит OpenVPN как часть аварийного переключения. Таким образом, OpenVPN пытается работать на всех узлах кластера. Преобразование для прослушивания IP-адреса кластера приводит к тому, что система распознает, что OpenVPN требует аварийного переключения, и работает правильно на всех узлах.
Задача решена. Ура!