» Firewall *nix: iptables, ipfw, pf etc...

Alukardd

Код: iptables -t nat -A POSTROUTING -o $INET -j SNAT --to-source $INETIP

и так вспомним что такое активный режим, клиент создает соединение с рандомного порта (выше 1024) на 21 порт сервера и в поле данных пакета передает привет, имя пароль и рандомный порт на котором он ждет подключения со стороны сервера, после чего сервер это соединение и устанавливает с 20 порта. Соответственно никакими правилами уровня L3 на фаерволе этого не сделать - нужна инспекция протокола FTP (как это делает cisco, isa, kerio и другие)
фаервол получая пакет от локального компьютера адресованный хосту в интернете на порт 21 извлекает из него данные, а именно команды FTP, узнает порт на который ожидает подключение клиент и динамически открывает его у себя.
При пассивном режиме наоборот сервер сообщает клиенту рандомный порт на котором он ждет передачи данных, соответственно правила на фаерволе можно сделать и без инспекции, но очень "некрасивые" - клиенту нужно разрешить порты 21 + 1024-65535

Если за натом находится не клиент а сервер то без инспекции:
для активного режима нужно маппить на него 21 порт и разрешить ему подключения с 20 порта к любому хосту на порты 1024-65535
а для пассивного маппить на него порты 21 + 1024-65535 что вообще недопустимо
хотя конечно в настройках самого сервера FTP этот диапазон (1024-65535) можно урезать в соответствии с ожидаемой нагрузкой.

Нашел вот такую штуку.
Подозрения сходные. Но продвижение нулевое.

Добавлено:
Спасибо всем откликнувшимся!!!

Оказалось: сам дурак. Маршрутов на FTP сервере не хватало (когда по VPN обращался, подсеть была та же). Сделал дефолтным маршрутом 0.70, сервер ответил.

На ворос от товарища LookingBal

Цитата:

выкладываю содержимое
файла rc.firewall в 6 фото

А почему не выложить всё это шедеврическое творение одним текстовым файлом?
И вопрос не в тему: а подчёркивали вы фломастером прямо на мониторе?


Цитата:

что сделал - добавил переменную
ovpnport="1194" (фото 1)
скопировал правила rdp (фото 5, фото 6)
заменил rdpport на ovpnport

должно заработать?

По идее - да.

Цитата:

у меня не заработало, но я забыл заменить tcp на udp, а проверить сейчас не могу, т.к. удаленный доступ к прокси так и не на строил.

А в настройках openvpn-сервера указано udp?

Цитата:

а какой прогой можно наверняка проверить открытость порта от точки до точки? а то вдруг у меня уже всё работает и осталась проблема в настройках самой ОпенВПН?

telnet

urodliv
telnet не работает с udp. Тогда уж надо юзать netcat или уже nmap.

p.s. а кому хоть отвечали-то?)
Так бы и написали, что отвечали т. LookingBal на его вопрос.

Доброго времени суток!
Поставил IPFire. все работает, но не могу настроить проброс rdp-порта, я так понимаю у меня не прописан переход с сетевой 192.168.1.2 на 192.168.0.1
Т.к. в модеме (192.168.1.1) проброс на 192.168.1.2 прописал, в файерволе IPFire проброс на терминальный сервер 1С (192.168.0.55) прописал. При этом если я во внутренней сети подключаюсь по rdp к 192.168.1.2, то он пробрасывает на терминальный сервер 1С. А из внешки, когда обращаюсь на внешний IP проброса на терминальный сервер 1С не происходит.
Подскажите, пожалуйста, как прописать маршрут между двумя подсетями?

LookingBal
Я так и не понял, кто у вас за кем стоит и кем погоняет. Схему подключения нарисуйте.

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

есть виртуалка с поднятым в ней "debian6-роутером".
на роутере 3 интерфейса:
eth_ext - инет
eth_int - локалка
eth_vm - сеть между виртуалками и хостом
ifconfig: [more]eth_ext Link encap:Ethernet HWaddr 90:e2:ba:1b:86:f9
inet addr:195.144.x.x Bcast:195.144.x.x Mask:255.255.255.240
inet6 addr: fe80::92e2:baff:fe1b:86f9/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:902875 errors:0 dropped:0 overruns:0 frame:0
TX packets:563267 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1123390432 (1.0 GiB) TX bytes:103204959 (98.4 MiB)
Interrupt:9 Base address:0xe880

eth_int Link encap:Ethernet HWaddr 00:15:5d:00:99:01
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::215:5dff:fe00:9901/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:459565 errors:0 dropped:0 overruns:0 frame:0
TX packets:843773 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:146392583 (139.6 MiB) TX bytes:1034221786 (986.3 MiB)
Interrupt:9 Base address:0xec00

eth_vm Link encap:Ethernet HWaddr 00:15:5d:00:99:02
inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::215:5dff:fe00:9902/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:334152 errors:0 dropped:0 overruns:0 frame:0
TX packets:482988 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:71068571 (67.7 MiB) TX bytes:602116964 (574.2 MiB)
Interrupt:9 Base address:0xe800

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:4684 errors:0 dropped:0 overruns:0 frame:0
TX packets:4684 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:424239 (414.2 KiB) TX bytes:424239 (414.2 KiB)[/more]

также на роутере поднят pptpd.

так вот, проблема следующая - работает все, что нужно, за исключением форвардинга между pptp-клиентами, а также с роутрера нет доступа к сервисам клиентов
при подключении клиентов выполняется скрипт: [more]#!/bin/bash

IF_PPTP=${PPP_IFACE}
IP_PPTP=${PPP_REMOTE}

iptables -A FORWARD -s ${IP_PPTP} -i ${PPP_IFACE} -d 192.168.150.0/24 -j ACCEPT
iptables -A FORWARD -d ${IP_PPTP} -o ${PPP_IFACE} -s 192.168.150.0/24 -j ACCEPT

iptables -A FORWARD -s ${IP_PPTP} -i ${PPP_IFACE} -d 192.168.0.100/32 -p tcp -m tcp --dport 1515 -j ACCEPT
iptables -t nat -A PREROUTING -s ${IP_PPTP} -d 192.168.150.1/32 -i ${PPP_IFACE} -p tcp -m tcp --dport 1515 -j DNAT --to-destination 192.168.0.100:1515

iptables -A FORWARD -s ${IP_PPTP} -i ${PPP_IFACE} -d 192.168.0.99/32 -p tcp -m tcp --dport 1433 -j ACCEPT
iptables -t nat -A PREROUTING -s ${IP_PPTP} -d 192.168.150.1/32 -i ${PPP_IFACE} -p tcp -m tcp --dport 1433 -j DNAT --to-destination 192.168.0.99:1433
[/more]

iptables -nvL: [more]Chain INPUT (policy DROP 116 packets, 14388 bytes)
pkts bytes target prot opt in out source destination
8127 630K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:220
1295 68228 ACCEPT tcp -- eth_ext * 0.0.0.0/0 0.0.0.0/0 tcp dpt:1723
33135 6432K ACCEPT 47 -- * * 0.0.0.0/0 0.0.0.0/0
4261 381K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
2070 333K ACCEPT all -- eth_vm * 0.0.0.0/0 0.0.0.0/0
776K 613M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
3027 331K ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 0
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 11
5313 276K ACCEPT tcp -- eth_int * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3128
1241 79261 ACCEPT udp -- eth_int * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
1120 87540 ACCEPT udp -- eth_int * 0.0.0.0/0 0.0.0.0/0 udp dpt:137
13 656 ACCEPT tcp -- eth_int * 0.0.0.0/0 0.0.0.0/0 tcp dpt:445
11 560 ACCEPT tcp -- eth_int * 0.0.0.0/0 0.0.0.0/0 tcp dpt:139
549 127K ACCEPT udp -- eth_int * 0.0.0.0/0 0.0.0.0/0 udp dpt:138
0 0 ACCEPT udp -- eth_int * 0.0.0.0/0 0.0.0.0/0 udp dpt:139
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5269
56 2853 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5222

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
6194 8569K ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8
5972 8555K ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 0
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 11
26410 4923K ACCEPT all -- eth_vm eth_ext 0.0.0.0/0 0.0.0.0/0
102K 55M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
2442 125K TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
958 49804 ACCEPT tcp -- eth_int eth_ext 0.0.0.0/0 0.0.0.0/0 tcp dpt:443

Chain OUTPUT (policy ACCEPT 5346 packets, 1471K bytes)
pkts bytes target prot opt in out source destination
8798 483K TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU[/more]

iptables -nvL -t nat: [more]Chain PREROUTING (policy ACCEPT 2026 packets, 247K bytes)
pkts bytes target prot opt in out source destination
5313 276K REDIRECT tcp -- eth_int * 0.0.0.0/0 !192.168.1.0/24 tcp dpt:80 redir ports 3128

Chain POSTROUTING (policy ACCEPT 227 packets, 44194 bytes)
pkts bytes target prot opt in out source destination
11573 735K SNAT all -- * eth_ext 0.0.0.0/0 0.0.0.0/0 to:195.144.x.x

Chain OUTPUT (policy ACCEPT 669 packets, 73012 bytes)
pkts bytes target prot opt in out source destination
[/more]

в чем может быть затык?

kerevra
Скрипт который выполняется, я вообще не очень понимаю как он работает... Откуда он берёт переменные-то? И почему где-то используются переменные которые присваивают, а где-то в которые??? И вообще зачем это действие происходит?

И теперь самый главный вопрос... Почему нельзя написать общее правило для всех ppp клиентов?
Одно из правил — iptables -A FORWARD -s 192.168.0.1/24 -i eth_vm -d 192.168.150.0/24 -j ACCEPT

p.s. Если хотите показать адреса, то вместо вывода ifconfig намного приятнее читать ip -4 a s

Цитата:

Скрипт который выполняется, я вообще не очень понимаю как он работает... Откуда он берёт переменные-то? И почему где-то используются переменные которые присваивают, а где-то в которые???

переменные PPP_IFACE и PPP_REMOTE создает pptpd и закидывает туда ip и название инетрфейса, а IF_PPTP и IP_PPTP появились из копипаста скрипта. лежат скрипты в /etc/ppp/ip-up.d и /etc/ppp/ip-down.d (отличаются только назначением - добавление или удаление правил) и запускаются автоматом при подключении и отключении клиента соответственно. вопрос не в том, отрабатывают скрипты или нет, вопрос в том что при подключении клиента создается правило разрешающее форвардинг пакетов, но оно не работает

Добавлено:

Цитата:

И теперь самый главный вопрос... Почему нельзя написать общее правило для всех ppp клиентов?
Одно из правил — iptables -A FORWARD -s 192.168.0.1/24 -i eth_vm -d 192.168.150.0/24 -j ACCEPT

да можно, просто сначала не хотел всем клиентам разрешать все и было вместо "-d 192.168.150.0/24" что-то вроде "-d 192.168.150.100/32". подправил, так и оставил. но это же большого значения не имеет, не так ли?


Цитата:

p.s. Если хотите показать адреса, то вместо вывода ifconfig намного приятнее читать ip -4 a s

за это спасибо, не знал


Добавлено:
P.S.: при изменении -P FORWARD на ACCEPT положение не меняется

kerevra
Дык где Ваши отработанные правила при подключении клиентов? В выводе iptables я их не наблюдаю что-то...

P.P.S.: возможно ключевой момент - клиенты к сервисам сервера цепляются отлично, но не наоборот. также при пинге клиентов с сервера echo request до клиента доходит, echo reply не возвращается

Добавлено:
Alukardd
в момент iptables -nvL не было подключенных клиентов

вот вывод при наличии таковых: [more]Chain INPUT (policy DROP 1 packets, 328 bytes)
pkts bytes target prot opt in out source destination
8623 679K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:220
1302 68904 ACCEPT tcp -- eth_ext * 0.0.0.0/0 0.0.0.0/0 tcp dpt:1723
33201 6438K ACCEPT 47 -- * * 0.0.0.0/0 0.0.0.0/0
4573 410K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
2280 376K ACCEPT all -- eth_vm * 0.0.0.0/0 0.0.0.0/0
1051K 861M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
3986 446K ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 0
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 11
7499 390K ACCEPT tcp -- eth_int * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3128
1480 94488 ACCEPT udp -- eth_int * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
1301 102K ACCEPT udp -- eth_int * 0.0.0.0/0 0.0.0.0/0 udp dpt:137
19 956 ACCEPT tcp -- eth_int * 0.0.0.0/0 0.0.0.0/0 tcp dpt:445
15 764 ACCEPT tcp -- eth_int * 0.0.0.0/0 0.0.0.0/0 tcp dpt:139
690 159K ACCEPT udp -- eth_int * 0.0.0.0/0 0.0.0.0/0 udp dpt:138
0 0 ACCEPT udp -- eth_int * 0.0.0.0/0 0.0.0.0/0 udp dpt:139
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5269
59 3009 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5222
0 0 ACCEPT tcp -- ppp0 * 192.168.150.100 0.0.0.0/0 tcp dpt:5280

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
6194 8569K ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8
5972 8555K ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 0
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 11
27043 5294K ACCEPT all -- eth_vm eth_ext 0.0.0.0/0 0.0.0.0/0
119K 65M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
3007 154K TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
1505 78248 ACCEPT tcp -- eth_int eth_ext 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
0 0 ACCEPT tcp -- ppp0 * 192.168.150.100 192.168.0.99 tcp dpt:3389
0 0 ACCEPT tcp -- ppp0 * 192.168.150.100 192.168.0.100 tcp dpt:3389
0 0 ACCEPT all -- ppp0 * 192.168.150.100 192.168.150.0/24
0 0 ACCEPT all -- * ppp0 192.168.150.0/24 192.168.150.100
0 0 ACCEPT tcp -- ppp0 * 192.168.150.100 192.168.0.100 tcp dpt:1515
0 0 ACCEPT tcp -- ppp0 * 192.168.150.100 192.168.0.99 tcp dpt:1433

Chain OUTPUT (policy ACCEPT 65 packets, 3612 bytes)
pkts bytes target prot opt in out source destination
11877 650K TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU[/more]

Добавлено:
мой ip 192.168.150.100, пинга до 192.168.150.0/24 за исключением сервера нет

kerevra
Я что-о упустил? Откуда взялась 150-я подсеть? Мб у Вас банально маршрутов не хватает?

Alukardd, 150я подсеть - клиенты pptpd.

Код: root@proxima:~# cat /etc/pptpd.conf
option /etc/ppp/pptpd-options
logwtmp
localip 192.168.150.1
remoteip 192.168.150.11-254

kerevra
Эм... А почему маршрут только до единственного клиента, а не до всей подсети?
И да, кстати, клиентам Вы прописываете маршрут до 192.168.0.0/24 подсети, а то откуда они узнают, что она за pptp сервером?..

p.s. раз уже показал Вам утилиту ip, то вот далее — ip r s. И самое главное, что ip, в отличии от ifconfig и route в некоторых дистрибутивах лежит в /bin, а не в /sbin, что позволяет юзеру без геморроя смотреть настройки.

Цитата:

А почему маршрут только до единственного клиента, а не до всей подсети?

маршруты автоматом создаются для каждого из клиентов при подключении, так как они находятся каждый за своим ppp-интерфейом


Цитата:

И да, кстати, клиентам Вы прописываете маршрут до 192.168.0.0/24 подсети, а то откуда они узнают, что она за pptp сервером?..

в моем случае клиентам не интересно знать какая сеть находится за vpn-сервером. они пользуются только службами сервера. и, в свою очередь, при подключении получают маршрут до сетки 192.168.150.0/24


Цитата:

p.s. раз уже показал Вам утилиту ip, то вот далее — ip r s. И самое главное, что ip, в отличии от ifconfig и route в некоторых дистрибутивах лежит в /bin, а не в /sbin, что позволяет юзеру без геморроя смотреть настройки.

а за это еще одно спасибо

kerevra
Цитата:

в моем случае клиентам не интересно знать какая сеть находится за vpn-сервером. они пользуются только службами сервера. и, в свою очередь, при подключении получают маршрут до сетки 192.168.150.0/24

О каких FORWARD правилах мы вообще тогда говорим? Нас интересуют только INPUT и OUTPUT тогда. FORWARD понадобится для взаимодействия между клиентами и для доступа в обычную локалку.

Только щас начинаю понимать общую картину вашей "кухни". К тому же я не знаком с pptp сервером, я только OpenVPN пользуюсь.


Цитата:

а за это еще одно спасибо

Я вообще пользуюсь только ip в GNU/Linux т.к. она на мой взгляд куда удобнее, чем ifconfig и route. Как видите одни сокращения чего стоят. Вообще рекомендую поближе познакомится с данной утилитой.

Цитата:

О каких FORWARD правилах мы вообще тогда говорим?

нет, мне все-таки нужен форвардинг пакетов от клиента к клиенту, которые находятся в одной подсети но за разными интерфейсами


Цитата:

К тому же я не знаком с pptp сервером

ну это я заметил)


Добавлено:
P.S.: примерно такие же правила прокатывали для "связи" pptpd-клиентов на других дистрах Linux

kerevra
На сколько я понял как там у Вас всё устроено, правила похожи на правильные... Надо смотреть на счётчик пакетов, да вооружаться tcpdump'ом. Как я понял Вы уже делали что-то аналогичное... Можем вместе посмотреть на попытки пакетов продраться к цели.

Alukardd
tcpdump'ом смотрел, request-пакеты уходят получателю, но вот reply не возвращаются. проблема в том, что не знаю чем просниффить pptp-подключение на клиенте под виндами. пинг сервера клиентом проходит нормально

Добавлено:
при этом, судя по активности интерфейса, клиент получает request-пакеты

Товарищи, встал вопрос о шейпировании трафика средствами iptables и tc. Итак имеем сервер с eth0 (смотрит в интернет) и eth1 (смотрит в локальную сеть). NAT и шейпер на одной машине. Создал правила для ограничения вхоядщей скорости локальной машине:

$tc class add dev eth1 parent 1:1 classid 1:UID htb rate 512kbit ceil 1mbit burst 1600
$tc filter add dev eth1 protocol ip parent 1:0 prio 1 handle UID fw flowid 1:UID
$fw -A FORWARD -s 0/0 -d UIP -j ACCEPT
$fw -A FORWARD -s UIP -d 0/0 -j ACCEPT
$fw -t mangle -A FORWARD -i eth0 -o eth1 -d UIP -j MARK --set-mark UID

На удивление даже работает (заисключением того что игнорит по какой то причине установленное значение ceil и режет трафик в соответствии с rate)

Теперь встал вопрос об ограничении исходящей скорости для локальной машины, накидал следующее:

$tc class add dev eth1 parent 1:1 classid 1:UID htb rate 512kbit ceil 1mbit burst 1600
$tc filter add dev eth1 protocol ip parent 1:0 prio 1 handle UID fw flowid 1:UID
$fw -A FORWARD -s 0/0 -d UIP -j ACCEPT
$fw -A FORWARD -s UIP -d 0/0 -j ACCEPT
$fw -t mangle -A FORWARD -i eth0 -o eth1 -d UIP -j MARK --set-mark UID

Вопрос, будет ли эта связка работать и резать скорость входящую и исходящую для локальной машины? И если можно то кто нить подскажите что делать c ceil значением в первом примере, так как хотелось бы чтобы ширина канала варьировалась от и до...

OxOyD
А чем первый блок правил отличен от второго?

urodliv
+1

OxOyD
Вы бы хоть у FORWARD поменяли бы интерфейсы местами. Ну и UID ваше надеюсь разное в разных правилах...

Цитата:

Вы бы хоть у FORWARD поменяли бы интерфейсы местами.

Этого мало. "Корневые" интерфейсы для входящего и исходящего трафика будут разные. Так что обождём авторскую правку.

urodliv
Цитата:

"Корневые" интерфейсы для входящего и исходящего трафика будут разные.

эту фразу я абсолютно не понял. Зато могу добавить что -d, на -s надо поменять)

"Резать" можно только исходящий трафик.
Значит в нотации автора "исходящий" трафик клиента надо резать на eth0, а "входящий" на eth1. Вот эти-то интерфейсы и будут считаться "корневыми" в правилах шейпинга.

Пардон второй блок не тот вставил

$tc qdisc add dev eth0 ingress
$tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0
$tc class add dev ifb0 parent 1:1 classid 1:UID htb rate 512kbit burst 1600
$tc filter add dev ifb0 protocol ip parent 1:0 prio 1 u32 match ip src UIP flowid 1:UID
$fw -t mangle -A FORWARD -i eth0 -o eth1 -s UIP -j MARK --set-mark UID

Добавлено:
Мне уже сказали что схема с ifb0 не пойдет, так как трафик транзитный, то схема будет аналогична первой, переписанная под второй интерфейс.

Добавлено:
Больше волнует вопрос по rate и ceil, почему скорость режется принимая лишь значение rate и совершенно игнорируя ceil.

Ни у кого нет вариантов почему в данном примере ограничение происходит лишь по rate-значению игнорируя ceil?

$tc class add dev eth1 parent 1:1 classid 1:UID htb rate 512kbit ceil 1mbit burst 1600
$tc filter add dev eth1 protocol ip parent 1:0 prio 1 handle UID fw flowid 1:UID
$fw -A FORWARD -s 0/0 -d UIP -j ACCEPT
$fw -A FORWARD -s UIP -d 0/0 -j ACCEPT
$fw -t mangle -A FORWARD -i eth0 -o eth1 -d UIP -j MARK --set-mark UID

для данного интерфейса по мимо очереди ничего не создано
tc qdisc add dev eth1 root handle 1: htb

Кто поможет разобраться?

OxOyD
Возможно не хватает родителя:
# tc class add dev eth1 parent 1: classid 1:1 htb rate 1mbit burst 16k

Товарищи, очень нужна Ваша помощь.
Нужно с помощью iptables (v1.4.2) обеспечить защиту сети от несанкционированного доступа.
Имеем:
Сервер Debian 5 Lenny. На нем крутится сервис SIP-телефонии на mysql.

eth0 - мир IP:80.11.15.157 (сеть 80.11.15.152/29)
eth1 - не задействован (в будущем будет локалка 192.168.2.100)

Маршрутизация:

Код: # route -n

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface

80.11.15.152 0.0.0.0 255.255.255.248 U 0 0 0 eth0

0.0.0.0 80.11.15.153 0.0.0.0 UG 0 0 0 eth0