Исходящий трафик с определённого хоста лl

DasTieRR

Люблю подстраховаться… с кабелем оно наверняка :)))

strio911

ПС У меня гейтвей ОПТа последним стоит

У меня тоже.

Создал правило: написал для проверки, что если адрес соурса 10.10.10.11 и порт назначения 80, то ходить через указанный шлюз (OPT)
cat /tmp/rules.debug

User-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>

dvserg

А кабель выдернуть ? ::)

DasTieRR

@strio911:

ПС У меня гейтвей ОПТа последним стоит

У меня тоже.

Создал правило: написал для проверки, что если адрес соурса 10.10.10.11 и порт назначения 80, то ходить через указанный шлюз (OPT)
cat /tmp/rules.debug

User-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 узнаёт (могу ошибаться)

strio911

А кабель выдернуть ?

Да я попробовал бы =), только во первых: не пойму зачем, во вторых я сейчас не рядом с файрволом, я по ВПН.
А просто 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>

Как в этой секции, отвечающей за генерацию нужно мне правила, указать, что интерфейс для выхода rl0 ???
Добавление <interface>opt1</interface> перед <gateway>111.111.111.110</gateway> не помогает (при парсинге XML выдается ошибка)

dvserg

Я думаю это недоработка или особенность - ищет интерфейс по гейтвею.
Если у Евгения есть время - посмотреть сорцы на этот счет и пообщаться с разрабами.

Eugene

Возможно тупой вопрос, но - если линк от провайдера один, то зачем два интерфейса WAN и OPT-WAN? Почему бы не сделать один WAN с виртуальными адресами? а там уж рути/нать трафик как хочешь… Чего-то я вас не догоняю сутра, братцы -(

Eugene

Да… и Евгений перешёл на другую работу, абсолютно никак несвязанную с pfSense, посему наверное скоро скажет проекту "до свидания" -(

strio911

один WAN с виртуальными адресами?

А чем это поможет? Ведь у меня от этого у меня не появиться возможность на основе PolicyBased routing перенаправлять исходящий трафик через нужный мне интерфейс.

Eugene

@strio911:

один WAN с виртуальными адресами?

А чем это поможет? Ведь у меня от этого у меня не появиться возможность на основе PolicyBased routing перенаправлять исходящий трафик через нужный мне интерфейс.

Если задача - перенаправлять через нужный интерфейс, то - нет, не появится, т.к. этот интерфейс перестанет существовать. Если задача - перенаправлять через/с нужный IP, то всё решится.
Если не секрет - зачем через отдельный интерфейс если всё равно к одному провайдерскому шлюзу?

strio911

Если задача - перенаправлять через/с нужный IP, то всё решится.

Да в принципе на данный момент именно такая задача. Но как это сделать что-то не приложу ума как.

зачем через отдельный интерфейс если всё равно к одному провайдерскому шлюзу?

Просто так исторически сложилось (были/осталась задумки).

Eugene

@strio911:

Если задача - перенаправлять через/с нужный 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 (порядок правил должен быть именно такой). Всё собственно.

strio911

Евгений, спасибо! :)
Этот рецепт помог.

Только вот:

Я думаю это недоработка или особенность - ищет интерфейс по гейтвею.
Если у Евгения есть время - посмотреть сорцы на этот счет и пообщаться с разрабами.

Если всё-таки будет вариант "попинать" девелоперов было бы неплохо реализовать именно как я понял. Чтобы выбор шлюза ещё соответствовал интерфейсу.
В данный момент такой нужды нет, но теоретически такая фенечка была бы очень кстати (хотя скорее всего только для моих сверхмаразматичных задач ::) ).

Ещё раз спасибо. (Решено)

dvserg

Сначала нужно на 2.0 проверить. Ветку 1.2 думаю уже никто копать не будет.