Маршрутизация правилами



  • Добрый день!
    Помогите, пожалуйста ... у меня проблема в настройке маршрутизации с помощью правил (Policy Routing).
    Версия pfSense 2.4.4 p2

    7387ea2b-c1f9-404a-9634-6e7d9b804787-изображение.png

    1. Между PC1 - PC2 должна быть отказоустойчивая связь
      ping идет, но трассировка не работает.

    с PC1
    7a38f0ae-6a64-4ce9-a1b4-e216e50de3aa-изображение.png
    b23c7c72-b16f-48e2-b63f-da30f52b81c3-изображение.png

    c PC2
    bad06212-eb2b-4414-a88c-d0ef010bc53c-изображение.png
    d355ec3f-70a3-43f5-9c2f-10226e80a0a5-изображение.png

    Если сбросить стейты, то может ситуация поменяться, на PC1 не будет работать трассировка, а на PC2 все ок.

    Что неправильно настроил?

    pfSense1
    d6889dd8-f576-4970-9cf8-ee87b1c387e3-изображение.png

    06367935-c5c8-4eed-b5df-afb181701329-изображение.png

    pfSense2

    5707a87f-b176-4be7-ab48-93d20045cb01-изображение.png

    e7ba1856-4d60-4b0a-a6bb-5ba206cb76a3-изображение.png

    В Static Routes нигде ничего нет.

    1. Между PC1 - PC3 должна быть связь. Нужно ли применять Floating rules для этого? Если да, то на каких интерфейсах?


    1. Между PC1 - PC2 ведь есть связность, судя по icmp. Трассировка не видит все промежуточные хопы? А может, GIF скрывает их. 10.150.15.162 - это адрес gif интерфейса?

    2. А как связываете PC1 с PC3? Тоже policy-routing через gre? Или статические маршруты на gre? Чтобы трафик ходил через gre - надо назначить gre интерфейс и создать разрешающие правила на gre интерфейсе. Floating правила не нужны.



  • Спасибо за ответ!

    1. Связность по 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
    e116f41d-cdce-4a6a-8d6d-1e785c3843ee-изображение.png

    PC2
    c3fb63e7-bffa-4127-9637-c651cfad63a5-изображение.png

    Сбросил стейты и снова началось .....

    1. Связываю gre туннель между pfSense-1 и Mikrotik. Через Static Route проблем нет. Планирую связать через Policy Routing, вот и спрашиваю как должно быть.
      Начну делать когда по п.1 все станет стабильно и понятна будет методика.


    1. Не обращал внимания на трассировку при полиси-рутинге, но да - хоп LAN интерфейсов скрыт из-за него, скорее всего - так как TTL в пакете обычно уменьшается при выборе системой маршрута , а в полиси-рутинге pf (модуль стейтфул фаервола) выполняет работу вместо таблицы маршрутов. Если сбрасывать стейты фаервола, то по идее полиси-рутинг глушится - на время - так как он завязан на правила фаервола. И возможно, трассировка идет по маршруту в таблице (если он есть). Мне кажется, полиси-рутинг через два gif между pfsense 1 и 2 правильно настроен и работает.

    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-транзитный-трафик



  • @werter GIF для тестовой среды.
    RFC1918 там был еще транзитный трафик, не относящийся к данной проблеме.
    Считаю тоже, что все работает. Вопрос теперь 2 - транзитный трафик. Никак не получается.


Log in to reply