Исходящий трафик с определённого хоста лl
-
Доброго времени суток!
PfSense v.1.2.3
Три физических интерфейса (WAN, OPT, LAN);
Один провайдер, несколько белых статических адресов от него. (111.111.111.111/29, 111.111.111.112/29) - они же WAN и OPT соответственно;
LAN (10.10.10.10/24) - шлюз для локалки
Хост (10.10.10.11/24)Есть такая задача (проблема):
Трафик С этого хоста должен идти с интерфейса OPT (т.е. с адреса 111.111.111.112) и это принципиально.
На него как бы проблем нет, а вот наоборот… уже мозг щиплет. Кто в теме подскажите пожалуйста каким
простым или сложным способом можно это сделать!?...
-
Доброго времени суток!
PfSense v.1.2.3
Три физических интерфейса (WAN, OPT, LAN);
Один провайдер, несколько белых статических адресов от него. (111.111.111.111/29, 111.111.111.112/29) - они же WAN и OPT соответственно;
LAN (10.10.10.10/24) - шлюз для локалки
Хост (10.10.10.11/24)Есть такая задача (проблема):
Трафик С этого хоста должен идти с интерфейса OPT (т.е. с адреса 111.111.111.112) и это принципиально.
На него как бы проблем нет, а вот наоборот… уже мозг щиплет. Кто в теме подскажите пожалуйста каким
простым или сложным способом можно это сделать!?...Попробуйте создать в файевроле для этого хоста правило (для нужных сервисов) и указать шлюз для него не дефолт, а интерфейс opt1.
-
Попробуйте создать в файевроле для этого хоста правило (для нужных сервисов)
Правилами через ВЕБ-морду или руками? И какое правило на PF, 1:1 или Outbound?
Я бы если честно вообще создал бы статический маршрут с указанием что если source 10.10.10.11 то ходить тебе через этот интерфейс, но увы PfSnse штатно, то есть, чтобы потом можно было конфиг сохранить и восстановиться с него, так не умеет :(и указать шлюз для него не дефолт, а интерфейс opt1.
Это для адреса 10.10.10.11 указать шлюз 111.111.111.112? Но так работать не будет. ???
-
Попробуйте создать в файевроле для этого хоста правило (для нужных сервисов)
Правилами через ВЕБ-морду или руками? И какое правило на PF, 1:1 или Outbound?
Я бы если честно вообще создал бы статический маршрут с указанием что если source 10.10.10.11 то ходить тебе через этот интерфейс, но увы PfSnse штатно, то есть, чтобы потом можно было конфиг сохранить и восстановиться с него, так не умеет :(и указать шлюз для него не дефолт, а интерфейс opt1.
Это для адреса 10.10.10.11 указать шлюз 111.111.111.112? Но так работать не будет. ???
В Firewall rules на ЛАН создаем правило, разрешающее хосту ходить в инет а в правиле гейтвеем указываем ип ОПТа. Это называется PolicyBased routing - то есть правило с маршрутом. Надеюсь про порядок правил помним.
-
В Firewall rules на ЛАН создаем правило, разрешающее хосту ходить в инет. Надеюсь про порядок правил помним.
Помним ;D
в правиле гейтвеем указываем ип ОПТа. Это называется PolicyBased routing - то есть правило с маршрутом.
А вот здесь как выбрать именно интерфейс с которого будем ходить? У меня оба внешних IP из одной подсети и естественно у них один и тот-же шлюз (111.111.111.110/29)
и при создании этого самого правила в выпадающем списке выдаёт просто мне default, 111.111.111.110, 111.111.111.110, т.е. по шлюзу для каждого интерфейса, а они одинаковые.. -
Одблин.. точно ???
-
В Firewall rules на ЛАН создаем правило, разрешающее хосту ходить в инет. Надеюсь про порядок правил помним.
Помним ;D
в правиле гейтвеем указываем ип ОПТа. Это называется PolicyBased routing - то есть правило с маршрутом.
А вот здесь как выбрать именно интерфейс с которого будем ходить? У меня оба внешних IP из одной подсети и естественно у них один и тот-же шлюз (111.111.111.110/29)
и при создании этого самого правила в выпадающем списке выдаёт просто мне default, 111.111.111.110, 111.111.111.110, т.е. для по шлюзу для каждого интерфейса, а они одинаковые..Вот так, выделенное жирным шрифтом и показывает? Поставьте один из них, вытащите один из кабелей wan или opt1 и будет понятно, какой шлюз использует нужный комп.
-
В Firewall rules на ЛАН создаем правило, разрешающее хосту ходить в инет. Надеюсь про порядок правил помним.
Помним ;D
в правиле гейтвеем указываем ип ОПТа. Это называется PolicyBased routing - то есть правило с маршрутом.
А вот здесь как выбрать именно интерфейс с которого будем ходить? У меня оба внешних IP из одной подсети и естественно у них один и тот-же шлюз (111.111.111.110/29)
и при создании этого самого правила в выпадающем списке выдаёт просто мне default, 111.111.111.110, 111.111.111.110, т.е. для по шлюзу для каждого интерфейса, а они одинаковые..Вот так, выделенное жирным шрифтом и показывает? Поставьте один из них, вытащите один из кабелей wan или opt1 и будет понятно, какой шлюз использует нужный комп.
Лучше поставить и правила посмотреть. Если там на интерфейсах все сделано - то должно работать.
Правила в /tmp/rules.debugПС У меня гейтвей ОПТа последним стоит
-
Люблю подстраховаться… с кабелем оно наверняка :)))
-
ПС У меня гейтвей ОПТа последним стоит
У меня тоже.
Создал правило: написал для проверки, что если адрес соурса 10.10.10.11 и порт назначения 80, то ходить через указанный шлюз (OPT)
cat /tmp/rules.debugUser-defined rules follow
pass in quick on $lan proto tcp from { 10.10.10.11 } to <vpns>port = 80 keep state label "NEGATE_ROUTE: Negate policy route for local network(s)"
pass in quick on $lan route-to ( xl0 111.111.111.110 ) proto tcp from { 10.10.10.11 } to any port = 80 keep state label "USER_RULE"
pass in quick on $lan from 10.10.10.0/24 to any keep state label "USER_RULE: Default LAN -> any"зашёл для проверки на getip.ру. Как и ожидал показывает IP моего ван интерфейса.
На всякий случай указал и другой (такой же шлюз в выпадающем меню) эффект такой-же.</vpns>
-
А кабель выдернуть ? ::)
-
ПС У меня гейтвей ОПТа последним стоит
У меня тоже.
Создал правило: написал для проверки, что если адрес соурса 10.10.10.11 и порт назначения 80, то ходить через указанный шлюз (OPT)
cat /tmp/rules.debugUser-defined rules follow
pass in quick on $lan proto tcp from { 10.10.10.11 } to <vpns>port = 80 keep state label "NEGATE_ROUTE: Negate policy route for local network(s)"
pass in quick on $lan route-to ( xl0 111.111.111.110 ) proto tcp from { 10.10.10.11 } to any port = 80 keep state label "USER_RULE"
pass in quick on $lan from 10.10.10.0/24 to any keep state label "USER_RULE: Default LAN -> any"зашёл для проверки на getip.ру. Как и ожидал показывает IP моего ван интерфейса.
На всякий случай указал и другой (такой же шлюз в выпадающем меню) эффект такой-же.</vpns>
Для ICMP тоже сделай правило.
я не думаю, что он через 80 порт IP узнаёт (могу ошибаться) -
А кабель выдернуть ?
Да я попробовал бы =), только во первых: не пойму зачем, во вторых я сейчас не рядом с файрволом, я по ВПН.
А просто OPT отключить через вебморду не пойдёт?Для ICMP тоже сделай правило.
не думаю, что он через 80 порт IP узнаёт (могу ошибаться)Не поможет.
Вобщем поступил так:
в файле /tmp/rules.debug
нашёл строку в которой создано "неправильное" правило
pass in quick on $lan route-to ( xl0 111.111.111.110 ) proto tcp from { 10.10.10.11 } to any port = 80 keep state label "USER_RULE"
- жирным это WAN;
Заменил название интерфейса на нужное мне (2-ой WAN)
pass in quick on $lan route-to ( rl0 111.111.111.110 ) proto tcp from { 10.10.10.11 } to any port = 80 keep state label "USER_RULE"
после чего сделал pfctl -f /tmp/rules.debug …
И всё заработало :D
Но теперь другая проблема, как сделать чтобы это правило на постоянку "прилипло". ведь после перезагрузки файл с правилами генерируется заново из XML-файла конфигурации.
В XML пробывал посмотреть, но там описание этого правила имеет несколько другой вид:
<rule><type>pass</type>
<interface>lan</interface>
<max-src-nodes><max-src-states><statetimeout><statetype>keep state</statetype>
<os><protocol>tcp</protocol>
<source><address>10.10.10.11</address>
<destination><any><port>80</port></any></destination>
<descr><gateway>111.111.111.110</gateway></descr></os></statetimeout></max-src-states></max-src-nodes></rule>Как в этой секции, отвечающей за генерацию нужно мне правила, указать, что интерфейс для выхода rl0 ???
Добавление <interface>opt1</interface> перед <gateway>111.111.111.110</gateway> не помогает (при парсинге XML выдается ошибка) - жирным это WAN;
-
Я думаю это недоработка или особенность - ищет интерфейс по гейтвею.
Если у Евгения есть время - посмотреть сорцы на этот счет и пообщаться с разрабами. -
Возможно тупой вопрос, но - если линк от провайдера один, то зачем два интерфейса WAN и OPT-WAN? Почему бы не сделать один WAN с виртуальными адресами? а там уж рути/нать трафик как хочешь… Чего-то я вас не догоняю сутра, братцы -(
-
Да… и Евгений перешёл на другую работу, абсолютно никак несвязанную с pfSense, посему наверное скоро скажет проекту "до свидания" -(
-
один WAN с виртуальными адресами?
А чем это поможет? Ведь у меня от этого у меня не появиться возможность на основе PolicyBased routing перенаправлять исходящий трафик через нужный мне интерфейс.
-
один WAN с виртуальными адресами?
А чем это поможет? Ведь у меня от этого у меня не появиться возможность на основе PolicyBased routing перенаправлять исходящий трафик через нужный мне интерфейс.
Если задача - перенаправлять через нужный интерфейс, то - нет, не появится, т.к. этот интерфейс перестанет существовать. Если задача - перенаправлять через/с нужный IP, то всё решится.
Если не секрет - зачем через отдельный интерфейс если всё равно к одному провайдерскому шлюзу? -
Если задача - перенаправлять через/с нужный IP, то всё решится.
Да в принципе на данный момент именно такая задача. Но как это сделать что-то не приложу ума как.
зачем через отдельный интерфейс если всё равно к одному провайдерскому шлюзу?
Просто так исторически сложилось (были/осталась задумки).
-
Если задача - перенаправлять через/с нужный IP, то всё решится.
Да в принципе на данный момент именно такая задача. Но как это сделать что-то не приложу ума как.
Один WAN c 111.111.111.111/29.
На WAN создаёшь Proxy-ARP виртуальный IP 111.111.111.112.
Далее трафик с хоста 10.10.10.11/32 в OutboundNAT делаешь натить используя 111.111.111.112, а трафик с 10.10.10.0/24 - используя 111.111.111.111 (порядок правил должен быть именно такой). Всё собственно.