pfsense: соединение между двумя внутренними ланами разорвано через 20 секунд
У меня такой конфиг:
LAN 01: 192.168.16.0/24 (LAN for internal servers)
LAN 02: 192.168.67.0/24 (LAN for workstations)
WAN: X.X.X.X
А потом:
PFSENSE LAN IP: 192.168.16.1
PFSENSE LAN IP: 192.168.67.1 (it's a virtual IP)
LAN 01 и LAN 02 физически подключены (то есть в одном коммутаторе. Я знаю, что мне следует использовать отдельные локальные сети или, по крайней мере, виртуальные локальные сети на них, но сейчас я не могу легко изменить эту конфигурацию).
У меня работает установка PFSENSE (2.2), где компьютеры в LAN 02 получить свои IP-адреса от DHCP-СЕРВЕРА и использовать PFSENSE в качестве шлюза по умолчанию.
Вот моя проблема:
Если я сижу на компьютере, находящемся на LAN 02 и я ssh (или любой другой постоянный протокол в этом отношении) на сервер, находящийся на LAN 01 как это:
$ ssh -l myself 192.168.16.25
Подключаюсь без проблем. Соединение длится от 20 до 30 секунд, а затем оно постоянно разрывается.
Итак, мой вопрос: Что я могу сделать, чтобы соединение не разорвалось?
Я сделал tcpdump с обеих сторон, и в какой-то момент пакеты начали дублироваться. Выглядит это так:
У меня включена эта опция, и я думал, что это поможет, но этого не произошло.
Я должен упомянуть, что эта точно такая же конфигурация с использованием LINUX FIREWALL (iptables) работает отлично.
Любые идеи?
У меня была очень похожая проблема, и проблема заключалась, по сути, в разновидности асимметричной маршрутизации.
С моей топологией у меня есть блок PFSENSE с двумя интерфейсами LAN - оба / 24, но определенно разные подсети. Затем у меня есть коммутатор L2 \ L3, который соединяет оба интерфейса с остальной частью сети в разных VLAN. Также на этом переключателе свисают пользователи с проводной связью и сегмент, в котором есть все пользователи беспроводной сети. Пользователи с проводным подключением находятся в одной подсети \ VLAN, а беспроводные - в другой - и обе эти подсети существуют в блоке PFSENSE. Все конечные точки используют IP-адрес PFSENSE для своей соответствующей подсети в качестве своего DG. И, наконец, коммутатор также имеет IP-адреса в обеих вышеупомянутых подсетях.
Моя проблема заключалась в том, что если бы я был подключен по беспроводной сети и подключился к коммутатору по SSH, я бы подключился нормально, а затем отключился через 20-30 секунд. Как вы, вероятно, уже понимаете, поскольку IP-адрес коммутатора находится в той же подсети, что и моя машина, ответные пакеты от коммутатора будут идти прямо на мою машину, а не по тому же пути, что и пакеты с моей машины. Переключатель, по сути, просто обошел бы блок PFSENSE.
Во многих ситуациях это действительно может работать нормально, особенно для посредников без сохранения состояния и \ или сеансов UDP. Однако блок PFSENSE - это устройство с отслеживанием состояния, поэтому через несколько секунд PFSENSE не видит ответа на TCP OPEN и в конечном итоге убивает состояние. Для подтверждения вы можете настроить значение тайм-аута TCP OPEN в PFSENSE (Система -> Дополнительно -> Таймауты состояния), а затем заметить, что время, необходимое для сброса сеанса SSH, будет соответствовать установленному вами. По умолчанию для этого значения, как и ожидалось, 30 секунд. После удаления соответствующего IP с коммутатора - BAM - проблема исправлена.
Хотя это специально не упоминается в описанной топологии OP, я подозреваю, что между соответствующими конечными точками может быть переключатель (или аналогичный). Может быть, нет, но если так, то это может быть та же проблема, что и у меня здесь. В качестве альтернативы, эта проблема может возникнуть, если сервер в топо OP является двухкомпонентным.
Я предполагаю, что ваш список LAN1 и LAN2, поскольку оба 192.168.1.0/24 неверны, учитывая, что захват показывает, что один - 192.168.16.0, а второй - 192.168.67.0, по-видимому, надеюсь, оба / 24s.
Параметр статической фильтрации маршрута здесь не применяется.
Я предполагаю, что у вас либо перекрывающиеся сети (не маска / 24 на обоих, возможно, / 16 на некоторых хостах), либо одна из затронутых систем имеет двойное подключение в обеих сетях, что вызывает асимметричную маршрутизацию.