несколько внешних каналов с OpenBSD 4.7

На предыдущих версиях pf (до изменения синтаксиса в 4.7) разруливание нескольких внешних каналов замечательно работало. Решение было подсмотрено на http://www.openbsd.ru/files/etc/pf-dual.conf. Пришёл сервак, на котором с материнкой нармально работает только 4.7, предыдущие вылетают. Попытался сделать то-же самое, прочитал man и faq (http://openbsd.org/faq/pf/pools.html) - но увы. Вот по сути пример из FAQ:

ext_if_a = "em1"
ext_gw_a = "1.1.1.2"
ext_if_b = "em2"
ext_gw_b = "2.1.1.2"
int_if = "em0"
# натим оба внешних интерфейса
match out on $ext_if_a from 192.168.0.0/16 nat-to ($ext_if_a)
match out on $ext_if_b from 192.168.0.0/16 nat-to ($ext_if_b)
pass out on $ext_if_a
pass out on $ext_if_b
# перенаправляем пакет в правильный исходящий интерфейс
pass out on $ext_if_a from ($ext_if_b) route-to ($ext_if_b $ext_gw_b)
pass out on $ext_if_b from ($ext_if_a) route-to ($ext_if_a $ext_gw_a)
...
...

Что происходит? Оба внешних интерфейса пингуются, пакет уходит с правильного адреса. Т.е. на уровне icmp всё хорошо. Но любая tcp сессия (smtp, ssh итд) под правила роутинга не попадет и когда снаружи лезешь на канал который не является default gw - опаньки, пакеты пытаются уходить не с него. Соответственно, ничего не работает. Почитал что для пакетов с установлением сессии надо использовать reply-to - не помогло. Куда копать, может кто сталкивался уже?

Аватар пользователя hostage

/me посыпает

/me посыпает голову пеплом

Кажется, вчера сильно перетрудился или мало спал. Коллеги, я правильно понимаю, что для обслуживания входящих сессий надо ловить пакет на входе и через reply-to возвращать его на правильный интерфейс? То есть что-то типа

pass in on $ext_if_a inet proto tcp to ($ext_if_a) port { 22 25 } reply-to ($ext_if_a $ext_gw_a)
pass in on $ext_if_a inet proto tcp from ($ext_if_a:network) to ($ext_if_a) port { 22 25 }
pass in on $ext_if_b inet proto tcp to ($ext_if_b) port { 22 25 } reply-to ($ext_if_b $ext_gw_b)
pass in on $ext_if_b inet proto tcp from ($ext_if_b:network) to ($ext_if_b) port { 22 25 }

?

stainless steel mice

Аватар пользователя test00

разруливание

разруливание нескольких внешних каналов

я правильно понимаю, что для обслуживания входящих сессий надо ловить пакет на входе и через reply-to возвращать его на правильный интерфейс?
Я сам до конца не разобрался, но мораль в том, что в большинстве версий PF рутинг-опции для out-пакетов непрозрачно кастрированы по функционалу, поэтому если есть возможность, лучше всё делать на входящих. В 4.7 ваша задача решается адекватными менее костыльными интерфейсами, без всяких route-to - достаточно создать n таблиц рутинга (route -T) и потом скормить нужным правилам pf, обслуживающим in-пакеты, опцию rtable k, где k - номер таблицы. А балансировку, я полагаю, можно положить поверх этих правил. Можете глянуть слайд 25 отсюда: слайд 25 отсюда: http://www.atmnis.com/~proger/openkyiv/openkyiv2009_yunak_dynrouting.pdf, и вот этот топик может чем-то помочь: http://www.obsd.ru/8/?q=node/1705

Аватар пользователя hostage

частично заработало...

после...

# tcp сервисы
pass in on $ext_if_a inet proto tcp to ($ext_if_a) port { $tcp_svc } reply-to ($ext_if_a $ext_gw_a)
pass in on $ext_if_a inet proto tcp from ($ext_if_a:network) to ($ext_if_a) port { $tcp_svc }
pass in on $ext_if_b inet proto tcp to ($ext_if_b) port { $tcp_svc } reply-to ($ext_if_b $ext_gw_b)
pass in on $ext_if_b inet proto tcp from ($ext_if_b:network) to ($ext_if_b) port { $tcp_svc }
# udp сервисы
pass in on $ext_if_a inet proto udp to ($ext_if_a) port { $udp_svc } reply-to ($ext_if_a $ext_gw_a)
pass in on $ext_if_a inet proto udp from ($ext_if_a:network) to ($ext_if_a) port { $udp_svc }
pass in on $ext_if_b inet proto udp to ($ext_if_b) port { $udp_svc } reply-to ($ext_if_b $ext_gw_b)
pass in on $ext_if_b inet proto udp from ($ext_if_b:network) to ($ext_if_b) port { $udp_svc }

... этого извне cтал доступен по обоим интерфейсам, вне зависимости от default gateway

Но осталась проблема с пробросом портов внутрь:

# прокидываем и метим
pass in on $ext_if_a inet proto tcp from to ($ext_if_a) port 3389 tag EXT_IF_A rdr-to 192.168.10.1
pass in on $ext_if_b inet proto tcp from to ($ext_if_b) port 3389 tag EXT_IF_B rdr-to 192.168.10.1

# тэгированные раскладываем по их интерфейсам
pass in quick from ($ext_if_a:network) tagged EXT_IF_A
pass in quick inet tagged EXT_IF_A reply-to ($ext_if_a $ext_gw_a)
pass in quick from ($ext_if_b:network) tagged EXT_IF_B
pass in quick inet tagged EXT_IF_B reply-to ($ext_if_b $ext_gw_b)

не работает.... хотя до смены синтаксиса всё было в порядке. Где я ошибаюсь?

stainless steel mice

Аватар пользователя test00

По поводу

По поводу последних правил с pass in:
pass out тоже должен быть, нет? т.е. pass out from to ... tagged, т.к. после rdr пакеты снова проходят фильтрацию (не смотря на pass in rdr), впрочем, могу ошибаться. Но если я прав, то это не связано с изменением синтаксиса.
P.S: включите последним правилом логирование всех заблокированных пакетов, тогда tcpdump -i ... -e -n -ttt pflog0 block покажет, какие пакеты блочатся.

Аватар пользователя hostage

хмм... попробую,

хмм... попробую, спасибо

они не блокируются, получается сессия даже при обращении с default gw не устанавливается - tcpdump пакеты видит, они бегают, но telnet на 25й порт отшибает сразу (без таймаута). Похоже, как-то режутся флаги установления tcp сессии - понять глубже не хватает знания матчасти. Стоит убрать строки которые делают reply-to с tagged пакетом - с default gw проброс начинает работать.

Самое смешное, что раньше всё работало, то если либо что-то изменилось не только на уровне синтаксиса или я неправильно пишу правило

stainless steel mice

Аватар пользователя test00

раньше всё

раньше всё работало, то если либо что-то изменилось не только на уровне синтаксиса или я неправильно пишу правило

Кое-где изменился порядок приоритета для правил (nat и rdr), выкинули no nat, no rdr... так что сложно сказать сходу.

Лично для меня опции reply-to и route-to магические, я не понимаю как они работают. Народ пишет правила, ориентируясь на готовые примеры. Что в точности происходит с пакетом при этом - не ясно. Не ясно и указание в мане на то, что правило лишь "создаёт состояние" - я действительно вижу по pftop что "состояние" создаётся, в смысле аккаунтинг идёт и по новому правилу, но пакеты в лоб новым правилом не обрабатываются, а как они обрабатываются и проходят fw при route-to - не знаю кому ведомо.