У меня следующая конфигурация:
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)
ЛВС 01иЛВС 02физически соединены (т. е. находятся в одном коммутаторе. Я знаю, что мне следует использовать отдельные локальные сети или, по крайней мере, виртуальные локальные сети на них, но сейчас я не могу легко изменить эту конфигурацию).
У меня установлена PFSENSE (2.2), работающая там, где компьютерыЛВС 02получают свои IP-адреса от DHCP-СЕРВЕРА и используют PFSENSE в качестве шлюза по умолчанию.
Вот моя проблема:
Если я сижу за компьютером, находящимся наЛВС 02и я подключаюсь по ssh (или любому другому постоянному протоколу) к серверу, расположенному наЛВС 01так:
$ ssh -l myself 192.168.16.25
Я подключаюсь без проблем. Соединение длится где-то 20-30 секунд, а затем постоянно обрывается.
Итак, мой вопрос:Что можно сделать, чтобы избежать обрыва соединения?
Я сделал tcpdump с обеих сторон и в какой-то момент пакеты начали дублироваться. Выглядит это так:
У меня эта опция включена, и я думал, что она поможет, но она не помогла.
Должен отметить, что эта же самая конфигурация, использующая LINUX FIREWALL (iptables), работает отлично.
Есть идеи?
решение1
Полагаю, что указание вами LAN1 и LAN2 как 192.168.1.0/24 неверно, поскольку захват показывает, что один из них имеет адрес 192.168.16.0, а другой — 192.168.67.0, надеюсь, что оба имеют адрес /24.
Опция статической фильтрации маршрутов здесь неприменима.
Я предполагаю, что у вас либо перекрывающиеся сети (не маска /24 на обеих, а, возможно, /16 на некоторых хостах), либо одна из затронутых систем имеет двойное подключение к обеим сетям, что приводит к асимметричной маршрутизации.
решение2
У меня была очень похожая проблема, и по сути она представляла собой разновидность асимметричной маршрутизации.
В моей топологии у меня есть блок PFSENSE с 2 интерфейсами 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 с коммутатора - БАМ - проблема устранена.
Хотя это и не упоминается конкретно в описанной топологии OP, я подозреваю, что между соответствующими конечными точками может быть коммутатор (или что-то подобное). Может быть, и нет, но если это так, то это может быть та же проблема, что и у меня. В качестве альтернативы, если сервер в топологии OP имеет двойной адрес, то эта проблема возникнет.