Работа OSPF маршрутов
-
@Moron
Вот смотрите ,
к серверу от офиса
192.168.12.0/24->10.1.0.2->10.1.0.25
и обратно
10.1.0.25->10.1.0.1->10.1.0.2->192.168.12.0/24
видите разницу ?сервер всегда ждет ответный пакет от 10.1.0.1 ( а получает ответы напрямую от 10.1.0.2 )
тут нужен NAT Reflection , по-моему ( чтобы 10.1.0.2 слал пакеты 10.1.0.1, а не напрямую 10.1.0.25)
или проще на сервере прописать 1 статический маршрут
192.168.0.0/16 через 10.1.0.2 -
@Konstanti said in Работа OSPF маршрутов:
@Moron
Вот смотрите ,
к серверу от офиса
192.168.12.0/24->10.1.0.2->10.1.0.25
и обратно
10.1.0.25->10.1.0.1->10.1.0.2->192.168.12.0/24
видите разницу ?Разницу вижу и понимаю, pfSense должно быть все равно, что пакет идет другим путем, но ему становится все равно когда я выключаю полностью farewall
сервер всегда ждет ответный пакет от 10.1.0.1 ( а получает ответы напрямую от 10.1.0.2 )
Тогда почему при статичном маршруте работает?
тут нужен NAT Reflection , по-моему ( чтобы 10.1.0.2 слал пакеты 10.1.0.1, а не напрямую 10.1.0.25)
Вижу, что проблема в фаерволе, pfSense блочит, а городить NAT не правильный подход
-
@Moron
абсолютно верно
у вас по таблице состояний не было первого пакета ( он пошел напрямую к серверу)
а флаги в правиле выставлены только на syn пакет
поэтому он блочит syn-ask ( ассиметричная маршрутизация )если так хочется гонять трафик через pf
попробуйте так в правиле lan интерфейса
-
@Moron said in Работа OSPF маршрутов:
Вижу, что проблема в фаерволе, pfSense блочит, а городить NAT не правильный подход
Так это вы сами такое делаете
Сделайте проще , пропишите 1 статический маршрут на сервере , и все , проблема решена
192.168.0.0/16 через 10.1.0.2 -
@Konstanti said in Работа OSPF маршрутов:
@Moron said in Работа OSPF маршрутов:
Вижу, что проблема в фаерволе, pfSense блочит, а городить NAT не правильный подход
Так это вы сами такое делаете
Сделайте проще , пропишите 1 статический маршрут на сервере , и все , проблема решена
192.168.0.0/16 через 10.1.0.2У меня так и прописано, чтобы работало. Но меня это не устраивает, т.к. могут быть вообще разные сети и каждую прописывать при наличии OSPF не правильно.
попробуйте так в правиле lan интерфейса
Не помогает, все равно не получается игнорировать LAN трафик -
@Moron
Вы сейчас сами усложняете себе жизнь
Но , это Ваше право
если отключить проверку флагов в правиле LAN интерфейса - есть заблокированные пакеты в логах или нет ?
а если так сделать ? ( tcp flags и state type)
или еще вариант решения - разнести сервер и chr в разные сети ( с помощью vlan )
-
@Konstanti said in Работа OSPF маршрутов:
@Moron
Вы сейчас сами усложняете себе жизнь
Но , это Ваше правоЭто не усложнение жизни, а распределение шлюзов по серверам) На том же CHR вообще проблем нет и все работает... pfSense никак не могу побороть, а оставлять без фаервола это смерть.
если отключить проверку флагов в правиле LAN интерфейса - есть заблокированные пакеты в логах или нет ?
а если так сделать ? ( tcp flags и state type)
или еще вариант решения - разнести сервер и chr в разные сети ( с помощью vlan )
Вообще самый крайний вариант. Изучаю https://docs.netgate.com/pfsense/en/latest/troubleshooting/asymmetric-routing.html
-
State type=Sloppy ?
-
-
@Moron
А почему нельзя разнести CHR и сервер по разным сетям ? Например , с помощью VLAN и PF ? И проблема решена . Заодно
изолируете сервер от второй точки выхода в инет. По-моему , сейчас Вы идете очень извилистым путем -
@Konstanti said in Работа OSPF маршрутов:
@Moron
А почему нельзя разнести CHR и сервер по разным сетям ? Например , с помощью VLAN и PF ? И проблема решена . Заодно
изолируете сервер от второй точки выхода в инет. По-моему , сейчас Вы идете очень извилистым путемПотому, что мой вариант на 146% рабочий если заменить pfSense на CHR, но мне это никто не даст сделать, как и разнести по vlan.
По этому ищу причину почему трафик не ходит -
@Moron
Попробуйте сделать так- отключаем эту опцию
- создаем floating правило для Lan интерфейса
проверяем с разными state type ( и есть ли какие-нибудь записи о блокировке пакетов в журналах файрвола ? )
-
так как у Вас PF запускается на виртуальной машине , то можно отключить еще и вот такую опцию
-
запустите tcpdump на Lan интерефейсе pf ( если можно , то покажите )
- отключаем эту опцию
-
@Konstanti said in Работа OSPF маршрутов:
@Moron
Попробуйте сделать так- отключаем эту опцию
- создаем floating правило для Lan интерфейса
проверяем с разными state type ( и есть ли какие-нибудь записи о блокировке пакетов в журналах файрвола ? )
-
так как у Вас PF запускается на виртуальной машине , то можно отключить еще и вот такую опцию
Моей радости нет предела! Правило в Floating помогло!
- отключаем эту опцию
-
Моей радости нет предела! Правило в Floating помогло!
Точно ?
Может помогло это ?
@Konstanti said in Работа OSPF маршрутов:
так как у Вас PF запускается на виртуальной машине , то можно отключить еще и вот такую опцию
Есть ли возможность проверить?
Зы. Ого. Так у ТС пф как ВМ? Я к тому что галка на Disable hw offload - это ПЕРВОЕ, что делают при развертывание пф как ВМ. И это описано в вики пф.
-
@werter said in Работа OSPF маршрутов:
Моей радости нет предела! Правило в Floating помогло!
Точно ?
Точно, у меня 2 места с такой пробоемой и правило в Floating сработало
Может помогло это ?
@Konstanti said in Работа OSPF маршрутов:
так как у Вас PF запускается на виртуальной машине , то можно отключить еще и вот такую опцию
Есть ли возможность проверить?
Зы. Ого. Так у ТС пф как ВМ? Я к тому что галка на Disable hw offload - это ПЕРВОЕ, что делают при развертывание пф как ВМ. И это описано в вики пф.
Было отключено изначально, везде про это пишут
