[Решено] System: Static Routes



  • Объясните пожалуйста, для чего существует вообще такая штука, как System: Static Routes ? По нормальному смыслу таблицы маршрутов, который я в нее вкладываю, она не рабочая в принципе!

    Я в ней прописываю маршруты к конкретным IP, которые собираюсь мониторить на соответствующих интерфейсах. Например, прописал гугловый 8.8.8.8/32 на первом интерфейсе с ADSL-модемом. И что я вижу по отвалу адсл ? Этот гугловый адрес преспокойно трассируется через второй ван-интерфейс, напрочь игнорируя Static routes. Соответственно, адсл-интерфейс не может "подняться" обратно, показывая статус "offline" в мониторинге.

    Как это лечить ?



  • @sweep4:

    Как это лечить ?

    Думаю учить матчасть.
    http://ts.psc.ru/CISCO/marginalii/csr.htm
    Статический маршрут обычно предназначен для тех случаев, когда роутер  не может динамически формировать маршрут для адресата.



  • @dvserg:

    @sweep4:

    Как это лечить ?

    Думаю учить матчасть.

    Какую матчасть ? Про то, что маршруты меняются при падении интерфейса ? Я разве где-то написал, что упал сам интерфейс ? ADSL-модем дозванивается сам до провайдера, и участок между ethernet-портом модема и pfSense не падает никогда. Почему собственно я и мониторю глобальный адрес, а не шлюз провайдера, которого я не могу знать.

    Так вот, в этой ситуации маршрут игнорируется.



  • Ну и..
    Канал упал, статический маршрут недоступен.
    Что должна делать система, если публичный сервер доступен по второму каналу?



  • @dvserg:

    Ну и..
    Канал упал, статический маршрут недоступен.
    Что должна делать система, если публичный сервер доступен по второму каналу?

    Статический маршрут первичен, я правильно понимаю ситуацию ? Он задан однозначно и по моему желанию. Система должна ему следовать, т.е. доступа к указанному адресу/подсети не должно быть.

    Вот еще интересный момент в этой истории. ADSL-модем переконнектился к провайдеру. Но pfSense по прежнему шлет вместо указанного статика самовольно через второй ван-интерфейс. Что ж, выдергиваю линк из второго ван-интерфейса. Физически. И что же вы думаете ? Думаете, маршрут пошел обратно через первый ван-интерфейс на adsl-модем ? Нееееееетушки! Он в статусе "как бы offline". И pfSense даже не думает на него поворачивать. Показывает два ван-интерфейса в оффлайне по мониторингу и точка.

    Выводы ? Static routes косячат. Что-то там недоработано.



  • Статический маршрут первичен, я правильно понимаю ситуацию ? Он задан однозначно и по моему желанию. Система должна ему следовать, т.е. доступа к указанному адресу/подсети не должно быть.
    

    Если статический маршрут недостижим система ищет другой путь. На то и маршрутизация. Ваш monitor-IP должен разрешаться только через тот интерфейс с которого вы его мониторите (шлюз прова)



  • @dvserg:

    Если статический маршрут недостижим система ищет другой путь. На то и маршрутизация. Ваш monitor-IP должен разрешаться только через тот интерфейс с которого вы его мониторите (шлюз прова)

    Возьмем, к примеру, моего второго провайдера, на втором ван-интерфейсе. В его подсети есть три IP-адреса, которые доступны только в рамках этой сети - биллинг, почтовый сервер и DNS. Больше они ниоткуда недоступны. Я именно этот факт и обозначаю соответствующими статическими маршрутами. А иначе, для чего они вообще тогда нужны ?

    Я считаю - такое поведение pfSense однозначно неправильное и багованное. Надо или исправлять, или хотя бы предоставлять возможность выбрать поведение статиков.

    И поставлю вопрос другим ребром - как в pfSense можно добиться, чтобы на определенные IP можно было ходить только через определенные интерфейсы (игнорируя failover и load balancing), если статиками этого не удается добиться ?

    И повторю вопрос еще раз - зачем тогда нужны static routes в-принципе ?



  • статические маршруты нужны!!!
    есть к примеру 2 выхода наружу из локалки, на одном по определению висит маршрут по умолчанию
    а 2 допустим подключен к другому офису и там есть своя куча сетей но по идее на вторую сеть будут посылаться пакеты если у них ип из той же сети. а если в этой сети стоит свой маршрутизатор то мы можем в статических маршрутах указать что тудым можно кидать пакеты и для других сетей. и не поверишь это работает. ничего косячного я у себя не наблюдаю.

    как вариант может не правильные маршруты сделал
    закинь пару скриншотов



  • Sweep4, вопросы очень правильные задаёшь. Да, static routes должны работать именно так, как ты говоришь. Я очень сильно подозреваю, что всё ломается, когда к этому делу привязывается failover/loadbalancing, у тебя это наличиствует?



  • @Evgeny:

    Sweep4, вопросы очень правильные задаёшь. Да, static routes должны работать именно так, как ты говоришь. Я очень сильно подозреваю, что всё ломается, когда к этому делу привязывается failover/loadbalancing, у тебя это наличиствует?

    Да, наличествует. Пока только failover на двух WAN-интерфейсах. Будет еще третий, тогда сделаю сложный вариантик - failover на трех интерфейсах и load balancing на двух.



  • Боюсь ошибиться, но кажись в релизе 2.0 что-то изменилось к лучшему. То есть, при отвале ADSL на первом ван-интерфейсе адрес 8.8.8.8/32 трассировался через второй ван-интерфейс, как и в RC3. Но при восстановлении адсл pfSense вроде как сумел поднять первый интерфейс обратно каким-то непонятным образом и пустить маршрут уже через него. Буду наблюдать за развитием событий  :)

    UPD: Нет, зря понадеялся - все также грустно.



  • Думаю, вместо static route в данном случае нужно использовать тот же Policy routing. Пропиши первым правилом для 8.8.8.8/32 ходить жёстко через заданный gateway, а статику для него можно убрать.



  • @Evgeny:

    Думаю, вместо static route в данном случае нужно использовать тот же Policy routing. Пропиши первым правилом для 8.8.8.8/32 ходить жёстко через заданный gateway, а статику для него можно убрать.

    Policy routing ? Это в каком разделе искать ? Или имеется в виду Firewall rules ?



  • @sweep4:

    @Evgeny:

    Думаю, вместо static route в данном случае нужно использовать тот же Policy routing. Пропиши первым правилом для 8.8.8.8/32 ходить жёстко через заданный gateway, а статику для него можно убрать.

    Policy routing ? Это в каком разделе искать ? Или имеется в виду Firewall rules ?

    Зачеркни всё, что я сказал про Policy routing - это только для трафика, проходящего через pfSense, но никак для исходящего из него. Сейчас я точно припоминаю - в 2.0, при определении monitoring IP для интерфейса этот трафик должен идти только через этот интерфейс без всяких статических маршрутов. Следовательно, возможно у тебя что-то не так сконфигурировано. Запости скриншоты gateway'ев с MonitoringIP и```
    pfctl -sr



  • Обращаю внимание - в качестве примера требуемого маршрута, который не относится к monitoring ip, приведен биллинг на втором провайдере. Который должен идти только через его интерфейс, а по факту идет через первый default gw.

    pfctl -sr
    
    scrub in on xl3 all fragment reassemble
    scrub in on bge0 all fragment reassemble
    scrub in on pppoe all fragment reassemble
    scrub in on bge1 all fragment reassemble
    anchor "relayd/*" all
    block drop in log all label "Default deny rule"
    block drop out log all label "Default deny rule"
    block drop in quick inet6 all
    block drop out quick inet6 all
    block drop quick proto tcp from any port = 0 to any
    block drop quick proto tcp from any to any port = 0
    block drop quick proto udp from any port = 0 to any
    block drop quick proto udp from any to any port = 0
    block drop quick from <snort2c> to any label "Block snort2c hosts"
    block drop quick from any to <snort2c> label "Block snort2c hosts"
    block drop in log quick proto tcp from <sshlockout> to any port = ssh label "sshlockout"
    block drop in log quick proto tcp from <webconfiguratorlockout> to any port = http label "webConfiguratorlockout"
    block drop in quick from <virusprot> to any label "virusprot overload table"
    block drop in on ! xl3 inet from 192.168.1.0/24 to any
    block drop in inet from 192.168.1.2 to any
    block drop in on ! bge0 inet from 10.99.99.0/24 to any
    block drop in inet from 10.99.99.1 to any
    block drop in on xl3 inet6 from fe80::260:8ff:fe8d:4025 to any
    block drop in on bge0 inet6 from fe80::20a:5eff:fe62:950e to any
    pass in on bge0 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "allow access to DHCP server"
    pass in on bge0 inet proto udp from any port = bootpc to 10.99.99.1 port = bootps keep state label "allow access to DHCP server"
    pass out on bge0 inet proto udp from 10.99.99.1 port = bootps to any port = bootpc keep state label "allow access to DHCP server"
    block drop in on ! pppoe inet from 94.190.14.61 to any
    block drop in on pppoe inet6 from fe80::2e0:18ff:fe3a:8639 to any
    block drop in inet from 94.190.14.61 to any
    block drop in on ! bge1 inet from 10.99.98.0/24 to any
    block drop in inet from 10.99.98.1 to any
    block drop in on bge1 inet6 from fe80::20b:cdff:fe52:7dc7 to any
    pass in on bge1 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "allow access to DHCP server"
    pass in on bge1 inet proto udp from any port = bootpc to 10.99.98.1 port = bootps keep state label "allow access to DHCP server"
    pass out on bge1 inet proto udp from 10.99.98.1 port = bootps to any port = bootpc keep state label "allow access to DHCP server"
    pass in on lo0 all flags S/SA keep state label "pass loopback"
    pass out on lo0 all flags S/SA keep state label "pass loopback"
    pass out all flags S/SA keep state allow-opts label "let out anything from firewall host itself"
    pass out route-to (xl3 192.168.1.1) inet from 192.168.1.2 to ! 192.168.1.0/24 flags S/SA keep state allow-opts label "let out anything from firewall host itself"
    pass out route-to (pppoe 94.190.64.41) inet from 94.190.14.61 to ! 94.190.14.61 flags S/SA keep state allow-opts label "let out anything from firewall host itself"
    pass in quick on bge0 proto tcp from any to (bge0) port = http flags S/SA keep state label "anti-lockout rule"
    pass in quick on bge0 proto tcp from any to (bge0) port = ssh flags S/SA keep state label "anti-lockout rule"
    anchor "userrules/*" all
    pass in quick on bge0 inet from 10.99.99.0/24 to 10.99.99.1 flags S/SA keep state label "USER_RULE: Allow LAN_Home to pfSense"
    pass in quick on bge0 inet from 10.99.99.0/24 to 10.99.98.0/24 flags S/SA keep state label "USER_RULE: Allow LAN_Home to LAN_Work"
    pass in quick on bge0 inet from 10.99.98.0/24 to 10.99.99.0/24 flags S/SA keep state label "USER_RULE: Allow LAN_Work to LAN_Home"
    pass in quick on bge0 route-to (xl3 192.168.1.1) inet from 10.99.99.0/24 to ! 10.99.99.0/24 flags S/SA keep state label "USER_RULE: Allow LAN to failover gateway"
    pass in quick on WANgroup proto tcp from any to any port 36300 >< 36304 flags S/SA keep state label "USER_RULE: Torrent ports"
    pass in quick on WANgroup proto udp from any to any port 36300 >< 36304 keep state label "USER_RULE: Torrent ports"
    pass in quick on WANgroup proto tcp from any to any port = 1194 flags S/SA keep state label "USER_RULE: OpenVPN Server port"
    block drop in quick on WANgroup proto tcp from any to any port 136 >< 140 label "USER_RULE: Block NETBIOS from any to WANgroup"
    block drop in quick on WANgroup proto udp from any to any port 136 >< 140 label "USER_RULE: Block NETBIOS from any to WANgroup"
    block drop in quick on WANgroup proto tcp from any to any port = microsoft-ds label "USER_RULE: Block MS-DS from any to WANgroup"
    block drop in quick on WANgroup proto udp from any to any port = microsoft-ds label "USER_RULE: Block MS-DS from any to WANgroup"
    block drop in quick on WANgroup proto tcp from any to any port = http label "USER_RULE: Block HTTP Server from any to WANgroup"
    block drop in quick on WANgroup proto udp from any to any port = http label "USER_RULE: Block HTTP Server from any to WANgroup"
    block drop in quick on WANgroup proto tcp from any to any port = https label "USER_RULE: Block HTTPS Server from any to WANgroup"
    block drop in quick on WANgroup proto udp from any to any port = https label "USER_RULE: Block HTTPS Server from any to WANgroup"
    block drop in quick on WANgroup proto tcp from any to any port = 9091 label "USER_RULE: Block Transmission web-access from any to WANgroup"
    block drop in quick on WANgroup proto udp from any to any port = 9091 label "USER_RULE: Block Transmission web-access from any to WANgroup"
    pass in quick on openvpn inet proto tcp from 10.99.98.0/24 to 10.99.100.0/24 flags S/SA keep state label "USER_RULE: Allow LAN_Work to OpenVPN network"
    pass in quick on openvpn inet proto udp from 10.99.98.0/24 to 10.99.100.0/24 keep state label "USER_RULE: Allow LAN_Work to OpenVPN network"
    pass in quick on openvpn inet proto tcp from 10.99.100.0/24 to 10.99.98.0/24 flags S/SA keep state label "USER_RULE: Allow OpenVPN network to LAN_Work"
    pass in quick on openvpn inet proto udp from 10.99.100.0/24 to 10.99.98.0/24 keep state label "USER_RULE: Allow OpenVPN network to LAN_Work"
    pass in quick on bge1 inet from 10.99.98.0/24 to 10.99.98.1 flags S/SA keep state label "USER_RULE: Allow LAN_Work to pfSense"
    pass in quick on bge1 inet from 10.99.98.0/24 to 10.99.99.0/24 flags S/SA keep state label "USER_RULE: Allow LAN_Work to LAN_Home"
    pass in quick on bge1 inet from 10.99.99.0/24 to 10.99.98.1 flags S/SA keep state label "USER_RULE: Allow LAN_Home to LAN_Work"
    pass in quick on bge1 inet proto tcp from 10.99.98.0/24 to 10.99.100.0/24 flags S/SA keep state label "USER_RULE: Allow LAN_Work to OpenVPN network"
    pass in quick on bge1 inet proto udp from 10.99.98.0/24 to 10.99.100.0/24 keep state label "USER_RULE: Allow LAN_Work to OpenVPN network"
    pass in quick on bge1 inet proto tcp from 10.99.100.0/24 to 10.99.98.0/24 flags S/SA keep state label "USER_RULE: Allow OpenVPN network to LAN_Work"
    pass in quick on bge1 inet proto udp from 10.99.100.0/24 to 10.99.98.0/24 keep state label "USER_RULE: Allow OpenVPN network to LAN_Work"
    pass in quick on bge1 route-to (pppoe 94.190.64.41) inet from 10.99.98.0/24 to ! 10.99.98.0/24 flags S/SA keep state label "USER_RULE: Allow LAN_Work to failover gateway"
    anchor "tftp-proxy/*" all</virusprot></webconfiguratorlockout></sshlockout></snort2c></snort2c>
    










  • Если пример - это кто-то из LAN идёт на 94.190.64.7, то static route нужно убрать, а в правилах на LAN прописать Gateway=GW_OPT1. В этом случае трафик всегда должен пытаться идти на OPT1, даже если он не работает.



  • @Evgeny:

    Если пример - это кто-то из LAN идёт на 94.190.64.7, то static route нужно убрать, а в правилах на LAN прописать Gateway=GW_OPT1. В этом случае трафик всегда должен пытаться идти на OPT1, даже если он не работает.

    Ну допустим этот частный случай таким образом решается. А в глобальном смысле ? Допустим заставить pfSense ходить на DNS второго провайдера только через его интерфейс ? Или site-to-site VPN по соответствующим интерфейсам растолкать ?

    По мониторингу IP - все же что-то в релизе поменялось. Я специально проверил несколько раз - после поднятия адсл обратно адрес стал трассироваться и мониториться через требуемый интерфейс. С убранным из static routes правилом тоже. Хоть по этой части что-то решилось, и то хорошо.



  • @sweep4:

    Ну допустим этот частный случай таким образом решается. А в глобальном смысле ? Допустим заставить pfSense ходить на DNS второго провайдера только через его интерфейс ? Или site-to-site VPN по соответствующим интерфейсам растолкать ?

    Вот тут должны работать static routes (трафик с самого pfSense), давай возьмём такой частный случай (не Monitoring IP) и посмотрим.



  • @Evgeny:

    @sweep4:

    Ну допустим этот частный случай таким образом решается. А в глобальном смысле ? Допустим заставить pfSense ходить на DNS второго провайдера только через его интерфейс ? Или site-to-site VPN по соответствующим интерфейсам растолкать ?

    Вот тут должны работать static routes (трафик с самого pfSense), давай возьмём такой частный случай (не Monitoring IP) и посмотрим.

    Я кажется понял, в чем дело. Тут вот какая нестыковочка получается. Дело в том, что трассировка непосредственно с pfSense из консоли похоже что работает. То есть идет на заданный адрес через заданный интерфейс согласно статику. А такая же трассировка с моего десктопа из локалки идет без учета статика на роутере, по всей видимости только через firewall rules. Вот такой нюанс получается. То есть, если нам потребуется пустить и сам pfSense и клиентов из сети куда-либо по заданным маршрутам - придется прописывать и статики, и правила firewall.



  • @sweep4:

    Я кажется понял, в чем дело. Тут вот какая нестыковочка получается. Дело в том, что трассировка непосредственно с pfSense из консоли похоже что работает. То есть идет на заданный адрес через заданный интерфейс согласно статику. А такая же трассировка с моего десктопа из локалки идет без учета статика на роутере, по всей видимости только через firewall rules. Вот такой нюанс получается. То есть, если нам потребуется пустить и сам pfSense и клиентов из сети куда-либо по заданным маршрутам - придется прописывать и статики, и правила firewall.

    Немножко не так.

    1. для трафика, сгенерированного самим pfSense'ом (пинг с консоли), работают статические маршруты
    2. для транзитного трафика (с LAN на WAN) работают статические маршруты если в правиле для данного трафика отсутствует Gateway, иначе трафик идёт через сконфигурированный в правиле Gateway.

Log in to reply