Policy Based Routing. Транзитный трафик.



  • Задача сделать вместо Static Routes - маршрутизацию правилами Policy Based Routing.
    PC-1 (172.16.74.224) <-> PC-2 (172.31.74.94) есть связь
    PC-i (192.168.5.181) <-> PC-2 (172.31.74.94) есть связь
    PC-1 (172.16.74.224) <-> PC-i (192.168.5.181) НЕТ СВЯЗИ!!!

    PC-1
    5e4ce8cf-4070-4636-9070-24e978b88df4-изображение.png
    14b0248a-bf7e-448d-a912-ecff5068f07a-изображение.png

    PC-2
    6f62a513-f761-4bfb-937e-223aef7abfd7-изображение.png
    a199ee5d-d0b8-4113-87d6-d16146f1f982-изображение.png
    60a6861b-b687-4391-9ae9-145f7415ff58-изображение.png

    PC-i
    f137ed48-3604-4589-bf7a-f2d17c76785c-изображение.png
    4ea5e3f5-3ebc-4dbf-96c9-d0fd0571a858-изображение.png

    Во Floating везде пусто.
    MTU 1500 везде.

    Все ли правила указал верно?



  • eff63ae6-ceec-4dab-9fd6-13ca9ddf298e-изображение.png



  • @panperm said in Policy Based Routing. Транзитный трафик.:

    PC-1 (172.16.74.224) <-> PC-i (192.168.5.181)

    Хм, то есть этот трафик дважды полиси-роутится - первый раз на ЛАНе pfsense-1, второй - на ГИФе pfsense-2
    Интересно, вылетает ли пинг с GIF_P2_I в сторону pfsense-I и возвращается ли. Надо послушать packet capture на всех хопах.
    Двойной полиси-рутинг - это непривычно как-то. Может, поднять еще GIF между сторонами 1 и I напрямую?



  • @vladimirlind said in Policy Based Routing. Транзитный трафик.:

    Хм, то есть этот трафик дважды полиси-роутится - первый раз на ЛАНе pfsense-1, второй - на ГИФе pfsense-2
    Интересно, вылетает ли пинг с GIF_P2_I в сторону pfsense-I и возвращается ли. Надо послушать packet capture на всех хопах.
    Двойной полиси-рутинг - это непривычно как-то. Может, поднять еще GIF между сторонами 1 и I напрямую?

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

    Сделано так для организации отказоустойчивой схемы, так как на каждом pfSense несколько WAN и предполагается, что вместе GIF будут GW_Group. Также есть задумка разделить нагрузку по каналам, сделать несколько GW_Group с разными WAN в приоритете.

    Если возможно, хотелось бы не делать лишних GIF. При количестве туннелей больше 30, web интерфейс начинает тормозить, а иногда совсем отваливаться, что лечится только перезапуском php-fpm из консоли.

    a93b097e-6116-42a9-8aa2-fe7bae99e3d6-изображение.png



  • @panperm Доброе утро
    Что является шлюзом по умолчанию у pF-1,pF-2 и pF-i ?



  • Получается не проходит трафик в месте с красной стрелкой

    0dd5b2f8-520f-4864-93b2-d719a51b17eb-изображение.png

    Похоже, что ошибка в правилах, ошибочное правило выключил, правильное добавил.

    848c8139-d61c-4107-810c-a22c03e7d787-изображение.png

    Но ситуация не изменилась.



  • Кажется, так работать не будет, так как PBR правила на GIF интерфейсах на pfsense-2 ломают reply-to.

    Покажите, пожалуйста, cat /tmp/rules.debug | grep reply-to на pfsense-2



  • @vladimirlind Я тоже так считаю, поэтому и спросил про шлюзы по умолчанию



  • @Konstanti said in Policy Based Routing. Транзитный трафик.:

    @panperm Доброе утро
    Что является шлюзом по умолчанию у pF-1,pF-2 и pF-i ?

    Шлюзы провайдеров, проверил в Diagnostics/Routes



  • @panperm
    Думаю , что именно "поломанная" функция reply-to не дает пакету нормально вернуться
    Я бы предложил сделать так , включить NAT OUTBOUND на интерфейсах GIF1 pF1 и GIF2 pF2
    Это для маршрута 74.224->5.181
    Только придется правила тоже немного подкорректировать на pF2, потому что источник поменяется



  • @vladimirlind said in Policy Based Routing. Транзитный трафик.:

    Кажется, так работать не будет, так как PBR правила на GIF интерфейсах на pfsense-2 ломают reply-to.

    Покажите, пожалуйста, cat /tmp/rules.debug | grep reply-to на pfsense-2

    /root: cat /tmp/rules.debug | grep reply-to
    block in quick on $WAN_E reply-to ( em0.2002 GW провайдера ) inet proto tcp from ! $admins_home_ips to any port 443 tracker 1555826053 flags S/SA label "USER_RULE"
    block in quick on $WAN_E reply-to ( em0.2002 GW провайдера ) inet proto tcp from ! $admins_home_ips to any port 3000 tracker 1556093819 flags S/SA label "USER_RULE"
    block in quick on $WAN_E reply-to ( em0.2002 GW провайдера ) inet proto tcp from ! $admins_home_ips to any port 22 tracker 1555826186 flags S/SA label "USER_RULE"
    pass in quick on $WAN_E reply-to ( em0.2002 GW провайдера ) inet from any to any tracker 1555826016 keep state label "USER_RULE"
    block in quick on $WAN_U reply-to ( em0.2000 GW провайдера ) inet proto tcp from ! $admins_home_ips to any port 22 tracker 1555826239 flags S/SA label "USER_RULE"
    block in quick on $WAN_U reply-to ( em0.2000 GW провайдера ) inet proto tcp from ! $admins_home_ips to any port 443 tracker 1555826225 flags S/SA label "USER_RULE"
    block in quick on $WAN_U reply-to ( em0.2000 GW провайдера ) inet proto tcp from ! $admins_home_ips to any port 3000 tracker 1556093845 flags S/SA label "USER_RULE"
    pass in quick on $WAN_U reply-to ( em0.2000 GW провайдера ) inet from any to any tracker 1555826212 keep state label "USER_RULE"
    block in quick on $WAN_EX reply-to ( em0.1240 GW провайдера ) inet proto tcp from ! $admins_home_ips to any port 3000 tracker 1556093945 flags S/SA label "USER_RULE"
    block in quick on $WAN_EX reply-to ( em0.1240 GW провайдера ) inet proto tcp from ! $admins_home_ips to any port 22 tracker 1555826280 flags S/SA label "USER_RULE"
    block in quick on $WAN_EX reply-to ( em0.1240 GW провайдера ) inet proto tcp from ! $admins_home_ips to any port 443 tracker 1555826267 flags S/SA label "USER_RULE"
    pass in quick on $WAN_EX reply-to ( em0.1240 GW провайдера ) inet from any to any tracker 1555826255 keep state label "USER_RULE"
    pass in quick on $GIF_P2_P1 reply-to ( gif0 10.150.15.161 ) inet from any to any tracker 1555826921 keep state label "USER_RULE"
    pass in quick on $GIF_P2_I reply-to ( gif3 10.150.16.126 ) inet from any to any tracker 1557315110 keep state label "USER_RULE"



  • Правила reply-to на месте, но они не срабатывают из-за более специфичных (с адресами сорса и назначения) route-to (PBR) правил. А что показывает cat /tmp/rules.debug | grep route-to ?

    @Konstanti да, идея с НАТ через GIF должна сработать



  • @vladimirlind said in Policy Based Routing. Транзитный трафик.:

    Правила reply-to на месте, но они не срабатывают из-за более специфичных (с адресами сорса и назначения) route-to (PBR) правил. А что показывает cat /tmp/rules.debug | grep route-to ?

    @Konstanti да, идея с НАТ через GIF должна сработать

    cat /tmp/rules.debug | grep route-to
    GWWAN_E_GW = " route-to ( em0.2002 GW провайдера ) "
    GWWAN_U_GW = " route-to ( em0.2000 GW провайдера ) "
    GWWAN_Ex_GW = " route-to ( em0.1240 GW провайдера ) "
    GWGIF_P2_I_TUNNELV4 = " route-to ( gif3 10.150.16.126 ) "
    GWGIF_P2_P1_TUNNELV4 = " route-to ( gif0 10.150.15.161 ) "
    GWGW_GROUP_ISP = " route-to { ( em0.2000 GW провайдера ) } "

    route-to can override that, causing problems such as in redmine #2073

    pass out route-to ( em0.2002 GW провайдера ) from WAN_E to !WAN_E Network/24 tracker 1000006961 keep state allow-opts label "let out anything from firewall host itself"
    pass out route-to ( em0.2000 GW провайдера ) from WAN_U to !WAN_U Network/29 tracker 1000006962 keep state allow-opts label "let out anything from firewall host itself"
    pass out route-to ( em0.1240 GW провайдера ) from WAN_Ex to !WAN_Ex Network/29 tracker 1000006963 keep state allow-opts label "let out anything from firewall host itself"
    pass out route-to ( gif0 10.150.15.161 ) from 10.150.15.162 to !10.150.15.160/30 tracker 1000006964 keep state allow-opts label "let out anything from firewall host itself"
    pass out route-to ( gif3 10.150.16.126 ) from 10.150.16.125 to !10.150.16.124/30 tracker 1000006965 keep state allow-opts label "let out anything from firewall host itself"

    Идея пропускать все через NAT мне не очень нравится сама по себе. Вы можете посоветовать другое решение для балансировки трафика и Failover?



  • Да, у себя посмотрел - когда указываешь шлюз в правиле на интерфейсе со шлюзом - на WAN, OpenVPN интерфейсе и т.д., то reply-to уже не добавляется. Наверное, нельзя заставить PF делать и route-to и одновременно reply-to.

    Ну да, как и у вас:

    pass out route-to ( gif0 10.150.15.161 ) from 10.150.15.162 to !10.150.15.160/30 tracker 1000006964 keep state allow-opts label "let out anything from firewall host itself"
    pass out route-to ( gif3 10.150.16.126 ) from 10.150.16.125 to !10.150.16.124/30 tracker 1000006965 keep state allow-opts label "let out anything from firewall host itself"

    Тут нет reply-to, поэтому обратному трафику нужен явный маршрут. PF не знает, куда возвращать пинг.
    Теоретически, можно сделать жуткие флоатинг правила для обратного трафика и пытаться его выгнать через GIF, но это уже из серии "как сломать фаервол".

    Решение - мой выбор OpenVPN туннели вместо GIF + OSPF на FRR. с ОSPF можно легко масштабировать вашу сеть - просто в облако протокола маршрутизации добавляете новые роутеры и всё. Тут гирлянда фаерволов вполне уместна. Только надо косты на интерфейсах правильно расставить, чтобы не возникла асимметрия - стейтфул фаерволы её не любят.



  • @Konstanti @vladimirlind Большое Спасибо!!



  • @vladimirlind said in Policy Based Routing. Транзитный трафик.:

    Ну да, как и у вас:
    pass out route-to ( gif0 10.150.15.161 ) from 10.150.15.162 to !10.150.15.160/30 tracker 1000006964 keep state allow-opts label "let out anything from firewall host itself"
    pass out route-to ( gif3 10.150.16.126 ) from 10.150.16.125 to !10.150.16.124/30 tracker 1000006965 keep state allow-opts label "let out anything from firewall host itself"

    А, на самом деле не эти правила, но тем не менее, если отфильтровать /tmp/rules.debug по GWGIF_P2_I_TUNNELV4 и GWGIF_P2_P1_TUNNELV4 - будут похожие правила. Так что сути не меняет.


Log in to reply