Маршрутизация правилами
-
Добрый день!
Помогите, пожалуйста ... у меня проблема в настройке маршрутизации с помощью правил (Policy Routing).
Версия pfSense 2.4.4 p2- Между PC1 - PC2 должна быть отказоустойчивая связь
ping идет, но трассировка не работает.
с PC1
c PC2
Если сбросить стейты, то может ситуация поменяться, на PC1 не будет работать трассировка, а на PC2 все ок.
Что неправильно настроил?
pfSense1
pfSense2
В Static Routes нигде ничего нет.
- Между PC1 - PC3 должна быть связь. Нужно ли применять Floating rules для этого? Если да, то на каких интерфейсах?
- Между PC1 - PC2 должна быть отказоустойчивая связь
-
-
Между PC1 - PC2 ведь есть связность, судя по icmp. Трассировка не видит все промежуточные хопы? А может, GIF скрывает их. 10.150.15.162 - это адрес gif интерфейса?
-
А как связываете PC1 с PC3? Тоже policy-routing через gre? Или статические маршруты на gre? Чтобы трафик ходил через gre - надо назначить gre интерфейс и создать разрешающие правила на gre интерфейсе. Floating правила не нужны.
-
-
Спасибо за ответ!
- Связность по icmp есть, но эта нестабильность с трассировкой ... не должно быть так.
Трассировка при policy routing "съедает" адреса pfSense 172.16.74.222 и 172.31.74.25, это нормально.
Адреса GIF туннеля
pfSense-1 10.150.15.161
pfSense-2 10.150.15.162
Вот сейчас сбросил стейты и трассировка стала нормальной.
PC1
PC2
Сбросил стейты и снова началось .....
- Связываю gre туннель между pfSense-1 и Mikrotik. Через Static Route проблем нет. Планирую связать через Policy Routing, вот и спрашиваю как должно быть.
Начну делать когда по п.1 все станет стабильно и понятна будет методика.
- Связность по icmp есть, но эта нестабильность с трассировкой ... не должно быть так.
-
-
Не обращал внимания на трассировку при полиси-рутинге, но да - хоп LAN интерфейсов скрыт из-за него, скорее всего - так как TTL в пакете обычно уменьшается при выборе системой маршрута , а в полиси-рутинге pf (модуль стейтфул фаервола) выполняет работу вместо таблицы маршрутов. Если сбрасывать стейты фаервола, то по идее полиси-рутинг глушится - на время - так как он завязан на правила фаервола. И возможно, трассировка идет по маршруту в таблице (если он есть). Мне кажется, полиси-рутинг через два gif между pfsense 1 и 2 правильно настроен и работает.
-
Policy-routing вполне будет работать. GRE вроде умеет reply-to, так что обратный трафик должен возвращатся куда надо.
-
-
@panperm
Нескромный вопрос.
Чем обусловлен выбор GIF в кач-ве туннеля? Тот же Openvpn прекрасно умеет failover , если явно объявить ovpn-интерфейсы и создать из них group. А надо, так и OSPF к этому делу прикрутить. И GIF не умеет шифрование.Зы. Зачем правило с RFC1918? Какова его роль? Получаетеся, что пф отправляет весь трафик для серых сетей (кроме 172.16.74|31.0/24) в Default GW. И тот, к-ый предназначен для сети за МТ тоже. И при этом у вас для сети за МТ имеется на пф1 static route. Странно как-то.
Зы2. Можно скрин таблицы марш-ции пф-ов при всех поднятых туннелях?
-
Немного изменил стенд, поэтому решил сделать новую тему.
https://forum.netgate.com/topic/143415/policy-based-routing-%D1%82%D1%80%D0%B0%D0%BD%D0%B7%D0%B8%D1%82%D0%BD%D1%8B%D0%B9-%D1%82%D1%80%D0%B0%D1%84%D0%B8%D0%BA -
@werter GIF для тестовой среды.
RFC1918 там был еще транзитный трафик, не относящийся к данной проблеме.
Считаю тоже, что все работает. Вопрос теперь 2 - транзитный трафик. Никак не получается.