Перенаправление локального трафика Freebsd

[sergeev 1]

Здравствуйте!

Есть сервер доступа freebsd(mpd), часть клиентов из сети 172.16.0.0/16 ходят через него в интернет,

и есть сеть 172.22.0.0/16 которым нужно заблокировать доступ в интернет и перебрасывать их запросы на веб-сервер(1.1.1.1) со страницей заглушкой.

На линуксе такое сделать получилось:

11857 571K DNAT tcp -- * * 172.22.0.0/16 0.0.0.0/0 to:1.1.1.1

1000 111K DNAT udp -- * * 172.22.0.0/16 0.0.0.0/0 to:1.1.1.1

 

Chain POSTROUTING (policy ACCEPT 217K packets, 21M bytes)

pkts bytes target prot opt in out source destination

34M 2458M MASQUERADE all -- * * 172.16.0.0/16 0.0.0.0/0

14532 792K MASQUERADE all -- * * 172.22.0.0/16 0.0.0.0/0

 

А как сделать это на фри?

[adeep 212]

man ipfw

/fwd

?

[natiss 16]

ipfw fwd - это и так понятно

проблема то намного глубже: в заголовке http-запроса имя домена

вот научите веб-сервер с виртуальными сайтами ответить на запрос "vkontakte.ru"

кстати

 

fwd | forward ipaddr | tablearg[,port]

Change the next-hop on matching packets to ipaddr, which can be

an IP address or a host name. The next hop can also be supplied

by the last table looked up for the packet by using the tablearg

keyword instead of an explicit address. The search terminates if

this rule matches.

 

If ipaddr is a local address, then matching packets will be for-

warded to port (or the port number in the packet if one is not

specified in the rule) on the local machine.

If ipaddr is not a local address, then the port number (if speci-

fied) is ignored, and the packet will be forwarded to the remote

address, using the route as found in the local routing table for

that IP.

A fwd rule will not match layer-2 packets (those received on

ether_input, ether_output, or bridged).

The fwd action does not change the contents of the packet at all.

In particular, the destination address remains unmodified, so

packets forwarded to another system will usually be rejected by

that system unless there is a matching rule on that system to

capture them. For packets forwarded locally, the local address

of the socket will be set to the original destination address of

the packet. This makes the netstat(1) entry look rather weird

but is intended for use with transparent proxy servers.

 

To enable fwd a custom kernel needs to be compiled with the

option options IPFIREWALL_FORWARD.

 

Во как интересно! Это к вопросу о построении запрещающих правил ipfw в таком случае.

[adeep 212]

К заголовкам - в чем проблема? апач отвечает первой конструкцией virtualhost при неизвестном имени домена

[maxx 202]

для начала отпределись чем вы натите, пфом или ипфв.

[stroitel 4]

PF:

rdr inet proto tcp from <deny_clients> to any port 80 -> $SERVER_IP port 80

[natiss 16]

К заголовкам - в чем проблема? апач отвечает первой конструкцией virtualhost при неизвестном имени домена

Не всегда удобно лепить первый виртуалхост страницей-отбойником. Кстати, nginx тоже отвечает первой конструкцией? А если имеем frontend-bakend?

Куда более красиво будет посылать header...

[ssalvadorx 0]

А c fwd точно получится, или для этого еще нужен SQUID?

[sergeev 1]

Натим ipfw

ipfw nat 12 config ip 2.2.2.2 same_ports reset

nat 12 ip from 172.16.0.0/16 to any out

nat 12 ip from any to 2.2.2.2 in

[natiss 16]

А c fwd точно получится, или для этого еще нужен SQUID?

"точно" не получится, я бы форвардил на поднятый на localhost nginx , который бы уже посылал клиентам нормально хидеры

С чего бы это сторонний веб-сервер ответил на пакет, предназначенный для vk.com?

А еще лучше, конечно же, proxy. Но зачем же монстрообразный squid, когда можно 3proxy?

[natiss 16]

Натим ipfw

ipfw nat 12 config ip 2.2.2.2 same_ports reset

nat 12 ip from 172.16.0.0/16 to any out

nat 12 ip from any to 2.2.2.2 in

Мне кажется, это заведомо "марш смерти". Попытки внести все существующие виды обработки пакетов в ipfw, заканчиваются плачевно. Например в соседней теме сервер не может обработать даже 100 мбит/с...

Чем короче и понятней дерево правил, тем лучше. Самый правильный ipfw (после случая, когда он выключен) - это add 1 pass all from any to any

[stroitel 4]

Натим ipfw

ipfw nat 12 config ip 2.2.2.2 same_ports reset

nat 12 ip from 172.16.0.0/16 to any out

nat 12 ip from any to 2.2.2.2 in

Чем короче и понятней дерево правил, тем лучше. Самый правильный ipfw (после случая, когда он выключен) - это add 1 pass all from any to any

А толк от него тогда?

[Gang 5]

Поднимите на том-же сервере на другом порту любой http сервер.

По критерию, который Вам нравится форвадите все запросы на 80-й порт на него. На нем вешаете заглушку. Остальное запрещаете.

 

ipfw add 20 fwd 127.0.0.1,1123 tcp from "table(40)" to any dst-port 80 in via vlan20 

 

В качестве примера.

 

P.S. Форвад работает только локально!

[natiss 16]

Поднимите на том-же сервере на другом порту любой http сервер.

По критерию, который Вам нравится форвадите все запросы на 80-й порт на него. На нем вешаете заглушку. Остальное запрещаете.

 

ipfw add 20 fwd 127.0.0.1,1123 tcp from "table(40)" to any dst-port 80 in via vlan20 

 

В качестве примера.

 

P.S. Форвад работает только локально!

Форвард как-раз работает нормально, просто надо понимать, что происходит. Пакет пересылается на указанный хост без изменения. Т.е., вместо кастера вконтакта пакет приходит на ваш веб-сервер, кторый его отфутболивает. В случае локального адреса вам "делают одолжение"

For packets forwarded locally, the local address

of the socket will be set to the original destination address of

the packet. This makes the netstat(1) entry look rather weird

but is intended for use with transparent proxy servers.

 

Локальный веб-сервер хорош, если имееет место запрос GET /. А если он запросит более сложный путь? В 3proxy теоретически работает конструкция

parent 1000 http 1.1.1.1

на практике, естественно, - нет.

Идем далее, если открывается сокет с адресом вконтакта, то что вы должны написать в ipfw? Вы должны разрешить ВСЁ (ну во всяком случае 80-ый порт) на внутреннем интерфейсе. А как вы это сделаете, если там форвардинг? Значит запрещающие правила надо на внешнем интерфейсе, а туда "мы" притулили nat и еще непойми-что. Получается "бред" (с).

[Gang 5]

Поднимите на том-же сервере на другом порту любой http сервер.

По критерию, который Вам нравится форвадите все запросы на 80-й порт на него. На нем вешаете заглушку. Остальное запрещаете.

 

ipfw add 20 fwd 127.0.0.1,1123 tcp from "table(40)" to any dst-port 80 in via vlan20 

 

В качестве примера.

 

P.S. Форвад работает только локально!

Форвард как-раз работает нормально, просто надо понимать, что происходит. Пакет пересылается на указанный хост без изменения. Т.е., вместо кастера вконтакта пакет приходит на ваш веб-сервер, кторый его отфутболивает. В случае локального адреса вам "делают одолжение"

For packets forwarded locally, the local address

of the socket will be set to the original destination address of

the packet. This makes the netstat(1) entry look rather weird

but is intended for use with transparent proxy servers.

 

Локальный веб-сервер хорош, если имееет место запрос GET /. А если он запросит более сложный путь? В 3proxy теоретически работает конструкция

parent 1000 http 1.1.1.1

на практике, естественно, - нет.

Идем далее, если открывается сокет с адресом вконтакта, то что вы должны написать в ipfw? Вы должны разрешить ВСЁ (ну во всяком случае 80-ый порт) на внутреннем интерфейсе. А как вы это сделаете, если там форвардинг? Значит запрещающие правила надо на внешнем интерфейсе, а туда "мы" притулили nat и еще непойми-что. Получается "бред" (с).

 

Нат не использую. Не понимаю в чем сложность во всем остальном ) Если запросит что-то окромя "GET /" - на локальном вебсервере редиректим все запросы на "/" (средствами вебсервера)

Я использую lighttpd. Там достаточно ловить 404 и перенаправлять куда нужно :

$SERVER["socket"] == ":1123" {
server.name = "lalalalala"
[b]server.error-handler-404 = "/index.html"[/b]
index.file-names = ( "index.html" )
server.document-root = "/usr/local/www/info"
}

На прошлой работе был шлюз на freebsd, отправлял на заглушку всех неугодных. Даже сообщения клиентам так слал.

Не далее как позавчера на новом участке сети сделал такую штуку : циска отправляет через PBR всех неугодных на сервер, который в общем и не роутит ничего, а для этого дела отдельный vlan интерфейс - все прекрасно работает.

 

Даже приведу рабочий больше не используемый пример с одного из серверов :

### Forwarding to blockpage
#${fwcmd} add 50003 fwd 127.0.0.1,1123 tcp from { not "table(5)" or not "table(40)" } to any dst-port 80 in via vlan333
#${fwcmd} add 50004 allow tcp from { not "table(5)" or not "table(40)" } to any via vlan333

vlan333 - интерфейс смотрящий в сеть.

[sergeev 1]

Натим ipfw ipfw nat 12 config ip 2.2.2.2 same_ports reset nat 12 ip from 172.16.0.0/16 to any out nat 12 ip from any to 2.2.2.2 in

Мне кажется, это заведомо "марш смерти". Попытки внести все существующие виды обработки пакетов в ipfw, заканчиваются плачевно. Например в соседней теме сервер не может обработать даже 100 мбит/с... Чем короче и понятней дерево правил, тем лучше. Самый правильный ipfw (после случая, когда он выключен) - это add 1 pass all from any to any

 

Ну у нас Nas-ы прокачивают в час пик до 350 мбит/с, ngX - около 500

[sergeev 1]

Значит получается у фри нету DNAT, и нужно ставить на насе ngnix и туда форвардить подсеть должников?

[Gang 5]

Значит получается у фри нету DNAT, и нужно ставить на насе ngnix и туда форвардить подсеть должников?

Вам выше подсказали посредством PF :

PF:

rdr inet proto tcp from <deny_clients> to any port 80 -> $SERVER_IP port 80

[sergeev 1]

Как то не очень хочется на насе держать два файервола. Сейчас поставил ngnix и туда сливаю подсеть. Думал может как-то можно обойтись одним ipfw.

[Gang 5]

Как то не очень хочется на насе держать два файервола. Сейчас поставил ngnix и туда сливаю подсеть. Думал может как-то можно обойтись одним ipfw.

А чем вы натите?

 

Не вижу ничего плохого в pf в связке с ipfw.

В своем время у меня НАТ был именно на pf.

 

UPDATE: увидел ipfw kernel nat

 

Ну вы можете сфорвадить на другой сервер. А там точно так-же использовать форвард уже локальный, как вариант. Но как по мне - все не имеет смысла. Оставляйте заглушку на насе и еже с ним.

Либо через pf )

[sergeev 1]

ipfw натим.

Ок, попробуем еще и pf.

[Ромка 567]

Мы перенаправляем неплательщиков через transporent proxy на заглушку.

[natiss 16]

Как то не очень хочется на насе держать два файервола. Сейчас поставил ngnix и туда сливаю подсеть. Думал может как-то можно обойтись одним ipfw.

Пакетных фильтра может быть? Вы еще скажите "брандмауэра"

Почему бы действительно не разделить ф-ции трансяции адресов и фильтрации пакетов?

[sergeev 1]

Как то не очень хочется на насе держать два файервола. Сейчас поставил ngnix и туда сливаю подсеть. Думал может как-то можно обойтись одним ipfw.

Пакетных фильтра может быть? Вы еще скажите "брандмауэра"

Почему бы действительно не разделить ф-ции трансяции адресов и фильтрации пакетов?

Ну ладно Вам, щас еще пошлёте учить матчасть

Ну а все таки, одним ipfw fwd можно организовать заглушку не используя на насе ngnix?

[natiss 16]

Ну а все таки, одним ipfw fwd можно организовать заглушку не используя на насе ngnix?

нет