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

OOD
Очередность абсолютно не важна, точнее именно в порядке очерёдности они и будут применяться.

Я полагаю что меняете вы некий файл и далее применяете его через iptables-restore /path/to/your/file? Эта строка была получена копированием предыдущей и изменением порта?
Так же хотелось бы увидеть именно ошибку которую Вам выводит iptables.

Alukardd
захожу в
/etc/sysconfig/
vi iptables

добавляю строки для правил NAT:
-A POSTROUTING -s [NAS-адрес]/32 -o eth1 -j MASQUERADE
сохраняю через qw
service iptables restart

NAT работает без проблем...
а вот если редактирую какую то строчку с портами -ничего не происходит
я уже думал что нужно как то по порядку прописывать порты...

ошибка была из-за того что подключался через putty к CentOS, больше не редактирую через Putty средствам Vi и все ок..

Здравствуйте уважаемые Форумчане. Поскромничал создавать отдельную ветку. Почитал соседние, там настоятельно рекомендовали задавать вопросы в этой. Так что не обессудьте.

Реализована такая схема.


Все хорошо, кроме одного - все девайсы нуждаются в настройке прокси вида proxy.domain.ru port 3128
На практике, это создает значительные сложности для доступа к интернету.

Если пропинговать proxy.domain.ru, получаю адрес ХХХ.ХХХ.ХХХ.ХХХ
И соотв. порт сохраняется 3128.

На сколько я понимаю - прокси - не прозрачный.

Dlink DIR-620 и прошит DD-WRT. Т.е. есть возможность прописать правила firewall в command shell через команды iptables.

Подскажите пожалуйста - какие команды надо применить чтобы трафик проходил через непрозрачный прокси по адресу ХХХ.ХХХ.ХХХ.ХХХ:3128

OOD
Цитата:

ошибка была из-за того что подключался через putty к CentOS, больше не редактирую через Putty средствам Vi и все ок..

kamadz
Цитата:

какие команды надо применить чтобы трафик проходил через непрозрачный прокси

весь или только http? Если только http, то:
iptables -t nat -A PREROUTING -p tcp --dport 80 ! -d <WAN_IP>/32 -s <LAN_NET>/<LAN_MASK> -j DNAT --to-destination XXX.XXX.XXX.XXX:3128
Только вот я совсем не уверен, что proxy настроенный в обычном (не прозрачном режиме) будет корректно обрабатывать запросы отправленные web-сайту "как-будто напрямую".

Я привык если уж за что-то браться, то доводить до конца - как минимум испробовать ВСЕ варианты.

Уважаемый Alukardd, если я правильно понял, то мне надо написать следующее:
iptables -t nat -A PREROUTING -p tcp --dport 80 ! -d <WAN_IP>/32 -s <LAN_NET>/<LAN_MASK> -j DNAT --to-destination XXX.XXX.XXX.XXX:3128



Если учитывать мои настройки ПК (справа), которые я по сути перенес на роутер (слева), то эта строка должна обрести какой вид?

kamadz
Я думал, что свои адреса Вы и сами подставить в состоянии...
iptables -t nat -A PREROUTING -p tcp --dport 80 ! -d 192.168.1.1/32 -s 192.168.1.1/24 -j DNAT --to-destination 192.168.81.1:3128

Alukardd
Спасибо огромное. Дело в том, что я не являюсь системным администратором и о Линукс знаю только то, что это ОС, которую начал развивать в свое время фин Линус Торвальдс.
Завтра смогу попробовать. Надеюсь все получится.

Добавлено:
Alukardd
Забыл написать, что у меня сам прокси имеет адрес 194.44.198.45:3128

Таким образов правильно ли я понимаю строка должна выглядеть так
iptables -t nat -A PREROUTING -p tcp --dport 80 ! -d 192.168.1.1/32 -s 192.168.1.1/24 -j DNAT --to-destination 194.44.198.45:3128

?

И, если можно, поинтерессуюсь у глубоко уважаемого Гуру - будет ли эта строка работать в условиях НЕ прозрачного прокси (логин и пароль не требуется, клонирование МАС адреса тоже)?

kamadz
Да, тогда так.
Вот я об этом и писал, что не уверен, что будет работать. Я не углублялся в то как именно прокси сервер обрабатывает трафик приходящий к нему по доброй воле и путём "заворота". Вроде разница не существенно, вроде доп. http заголовков X-Forwarded-For.

Цитата:

Да, тогда так.

Спасибо, завтра попробую.

Вопрос

Perfectus88
Есть ли разница какая именно машина будет включена в локалке? Если зависит от какой-то конкретной машины, то могут ли другие подключаться изнутри к серверу?

NetIN="192.168.1.0/24", префикс не забыли?
А где правила на подобии allow tcp from any to me dst-port 22 in?

Сервер стоит дома. За ним находятся: 1 машина + роутер, который служит в качестве точки доступа для ноута и прочей ерунды. Изнутри наружу доступ есть всегда и постоянно.

Цитата:

allow tcp from any to me dst-port 22 in

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

Код: redirect_port tcp ${IpOUT}:22 22 redirect_port tcp ${IpOUT}:21 21 redirect_port tcp ${IpOUT}:50000-50500 50000-50500 redirect_port tcp ${IpOUT}:80 80

Perfectus88

Цитата:

Есть ли разница какая именно машина будет включена в локалке? Если зависит от какой-то конкретной машины, то могут ли другие подключаться изнутри к серверу?

Добавлено:

Цитата:

разрешения дуются на уровне ната

я не очень силён в замысловатых правилах nat'а в ipfw, но интуитивно это выглядит как обычный redirect и не имеет ни какого отношения к фильтрам allow/deny. Видимо я ошибаюсь...

Цитата:

Есть ли разница какая именно машина будет включена в локалке? Если зависит от какой-то конкретной машины, то могут ли другие подключаться изнутри к серверу?

Есть только две машины как я уже писал...
Стационарник и ноут. Ноут стоит за роутером. Разницы нет.
Доступ есть на обоих машинах.

Perfectus88
Попытаюсь подытожить ситуацию: если внутри сети выключены все машины (видимо включая роутер), то на сервак снаружи не достучаться. Если хоть что-то внутри включено, то со всех сторон сервак прекрасно доступен.
Так?

Alukardd
Да. Именно. Но есть один момент. После выключения машины за сервером, он (сервер) еще какое то время принимает соединения, потом рубится все, включая пинги.
Обсуждение или скорее монолог идет и на лисяре

Добавлено:
Пардон. Роутер включен постоянно!

Perfectus88
Такс... Феномен с включением машин мне пока не ясен, но есть 2 косяка: 1 — правило с кучей redirect_port непонятно зачем вообще нужно т.к. ни номера портов ни адрес машины не меняется... 2 — это правило вообще не применяется, т.к. его затирает следующее, вы обоим дали номер nat 1.

Над феноменом пока думаю.

Alukardd
С правилами все в порядке. Гляньте на первый пример в этой статье http://www.lissyara.su/articles/freebsd/tuning/ipfw_nat/
Сегодня поменяю местами сетевушки, вернее кабели и посмотрим что будет

Perfectus88
Сорь, я add проглядел.
А тогда можно глянуть на вывод ipfw nat show config.

Alukardd
Сервер недоступен Приду домой через час полтора вышлю

Добавлено:
ipfw nat show config:

Код:
ipfw nat 1 config if alc0 log deny_in same_ports reset redirect_port tcp 80.80.80.80:80 80 redirect_port tcp 80.80.80.80:50000-50500 50000-50500 redirect_port tcp 80.80.80.80:21 21 redirect_port tcp 80.80.80.80:22 22

Всем здравствуйте.
Нарисовалась следующая проблема:
Есть kvm со своей виртуальной сетью, в которой есть http и smtp сервера.
iptables v1.4.12
На eth0 внешний IP, проброска портов настроена, почти все работает...
iptables -t nat -nvL
Chain PREROUTING (policy ACCEPT 135K packets, 11M bytes)
pkts bytes target prot opt in out source destination
140K 7523K DNAT tcp -- * * 0.0.0.0/0 $EXT_IP tcp dpt:80 to:$HTTP_IP:80
27 1620 DNAT tcp -- * * 0.0.0.0/0 $EXT_IP tcp dpt:25 to:$SMTP_IP:25

Chain INPUT (policy ACCEPT 8944 packets, 649K bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 5700 packets, 347K bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 152K packets, 8156K bytes)
pkts bytes target prot opt in out source destination
0 0 SNAT all -- * * 192.168.122.0/24 $HTTP_IP to:192.168.122.1
4 240 SNAT all -- * * 192.168.122.0/24 $SMTP_IP to:192.168.122.1
103 31702 MASQUERADE tcp -- * * 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535
141 9571 MASQUERADE udp -- * * 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535
0 0 MASQUERADE all -- * * 192.168.122.0/24 !192.168.122.0/24
в filter то же все нормально, сервисы доступны на внешнем IP и снаружи и из локальной сети виртуалки (т.е. с локального адреса на внешний адрес сервиса можно спокойно зайти), за одним исключением, если попытаться подключиться к сервисам с самих локальных серверов($HTTP_IP $SMTP_IP) через внешний адрес получим облом.
TRACE показывает, что пакет доходит до nat PREROUTING и даже срабатывает правило DNAT а дальше тишина...
Т.е. подключиться к самому себе через внешний адрес не получается.
Вопрос не в зачем а как сделать, серверами рулю не я.

omega27

Цитата:

за одним исключением, если попытаться подключиться к сервисам с самих локальных серверов

Все правильно. Гугли NAT loopback.

Спасибо за наводку, vlary.
С kvm до этого сталкиваться не приходилось, вот и упустил из виду мост.
Вечером попробую добавить интерфейсы к мосту, сейчас там нет внешней карты, только виртуальные.

omega27
А причём тут "мост" и kvm?
Единственный подвох, который связан с NAT Loopback — это то, что NAT'ить надо пакеты из локалки в локалку, НО на внешний интерфейс.

Подскажите пожалуйста как добавить статический маршрут через iptablel или конкурирование CentOs 6.0:
Под виндой это так:

Код:
route add -p 10.10.10.0 mask 255.255.255.0 192.168.1.1

В общем проблема такая:
есть Ubuntu 10.04, на 127.0.0.1:2080 слушает приложение. Заставить это приложение прослушивать адреса кроме 127.х.х.х нет возможности, но доступ к этому приложению надо получить из вне. В связи с этим хочу сделать редирект всех пакетов, приходящих на сетевой интерфейс, на 127.0.0.1:2080.

В системе имеется ufw (насколько я понял прослойка до iptables якобы для удобства).
В файле /etc/ufw/before.rules в самый конец прописал:


Код: *nat
: PREROUTING ACCEPT [0:0]
-A PREROUTING -p tcp -i eth0 --dport 2080 -j REDIRECT --to-ports 2080

COMMIT

bga83
Облом вашей ситуации в том, что вам надо менять исходящий адрес пакета на какой-нибудь из 127.х.х.х.
При этом использование REDIRECT`а не делает такого преобразования, Потому и скидывается ваш коннект. А SNAT задействовать не получится, так как он работает только в цепочке POSTROUTING.
Кругом облом.
Даже не знаю, что вам ещё посоветовать. Разве что назначить петлевому интерфейсу ограниченный диапазон адресов 127.х.х.х, а остальной попробовать задействовать для локальной сети ().

Цитата:

При этом использование REDIRECT`а не делает такого преобразования, Потому и скидывается ваш коннект. А SNAT задействовать не получится, так как он работает только в цепочке POSTROUTING.
Кругом облом.

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

Еще один вопрос касаемо специфики linux: после смены в пакете адреса назначения на 127.0.0.1 должен ли он проходить интерфейс обратной петли? когда смотрел tcpdump-ом, то там ничего не появлялось, хотя счетчик в redirect правиле увеличивается

PS после FreeBSD( с ipfw и pf) iptables вызывает некоторое недоумение

Я вашу фразу
Цитата:

Заставить это приложение прослушивать адреса кроме 127.х.х.х нет возможности

понял так: программа обладает собственной системой фильтрации и, если в tcp-пакете исходный адрес отличен от 127.х.х.х, то он самой программой не воспринимается. А squid`у-то в прозрачном проксировании всё равно какое значение исходного адреса, если мы не задавали этого сами, поэтому он и обрабатывает все пакеты.

Цитата:

Еще один вопрос касаемо специфики linux: после смены в пакете адреса назначения на 127.0.0.1 должен ли он проходить интерфейс обратной петли? когда смотрел tcpdump-ом, то там ничего не появлялось, хотя счетчик в redirect правиле увеличивается

Нет. При redirect`е меняет направление движения пакета: он идёт по ветке "локальных приложений".

Цитата:

PS после FreeBSD( с ipfw и pf) iptables вызывает некоторое недоумение

Встречный вопрос. А на фряхе вашу задачу реализовать удалось? Конечно, если это возможно.

Цитата:

понял так: программа обладает собственной системой фильтрации и, если в tcp-пакете исходный адрес отличен от 127.х.х.х, то он самой программой не воспринимается

а это мысль
вот об этом я и не подумал, не исключено, что в этом все дело, надо проверить


Проверил, действительно это приложение срезает коннекты от адресов не 127.х.х.х. Спасибо за озвученную мысль!

Дождешься тут блин, уже разобрался.