помогите с линуксом

Sokrat, 10.12.2003 09:39:22:

route add -net 192.168.4.0 netmask 255.255.255.0 gw 192.168.0.76

 

Да, для FreeBSD формат команды немного отличается, так что посмотрите man.

Sokrat, 10.12.2003 09:25:57:

postfix, exim, qmail - только не sendmail.

 

ок, не sendmail. я пока религиозных престрастий в этом не имею. интересно, что проше чайнику настроить?

УФ! как в анекдоте -колдун Сократ однако!
мда, и действитель, как я хотел одним гейтом обойтись?

Воощем, заработало. на клиентах инет пашет (во всяком случае http).

Вот такой вопрос: кидаю с машины с ip 192.168.0.76 192.168.4.1 команду
ping -I еth0 192.168.4.45

в ответ:
PING 192.168.4.45 (192.168.4.45) from 192.168.0.76 eth0: 56(84) bytes of data.
From 192.168.0.1: icmp_seq=1 Redirect Host(New nexthop: 192.168.0.76)

ну и так до без конца. с других ip сети 192.168.0.0 пинги на сеть 192.168.4.0 проходят. Т. е. получается, что пакеты проходят везде кроме как напрямую с одной сетевой сервера на другую. Это
1) так и должно быть
2) у меня Ping не правильный
3) руки кривые и что-то я опять недонастроил?

и теперь вторая часть вопроса - как собирать объём инфы, прошедшей через линуховый сервер на определёные ip адреса? В FreeBSD это решалось посредством count в ipfw + скидывание скриптом куда - нибудь. А тут как?

P. S. минус у Сократа - это очень неправильно

BrAB, 10.12.2003 11:25:15:

УФ! как в анекдоте -колдун Сократ однако!
мда, и действитель, как я хотел одним гейтом обойтись?

 

Я в первом же своем посте спросил об этом.

Вот такой вопрос: кидаю с машины с ip 192.168.0.76 192.168.4.1 команду
ping -I еth0 192.168.4.45

 

Думаю, "1) так и должно быть".

и теперь вторая часть вопроса - как собирать объём инфы, прошедшей через линуховый сервер на определёные ip адреса? В FreeBSD это решалось посредством count в ipfw + скидывание скриптом куда - нибудь. А тут как?

 

Аналогично - строятся цепочки для каждой машины во внутренней сети и периодически скидывается счетчик в файл/базу. Уверен, что по этому поводу десятки howto написаны.

Да, не забудь DROP для всех остальных поставить, чтобы не обошли счетчики.

BrAB, 10.12.2003 11:25:15:

и теперь вторая часть вопроса - как собирать объём инфы, прошедшей через линуховый сервер на определёные ip адреса? В FreeBSD это решалось посредством count в ipfw + скидывание скриптом куда - нибудь. А тут как?

 

На любом правиле в ipchains есть счетчики пакетов и байтов. Поглядеть их можно ipchains -L -v -x, опция -Z сбрасывает все счетчики в ноль. Т.е. пишете скрипт который разбирает вывод команды ipchains -L -v -n -Z и вперед.

Pazke, 10.12.2003 11:54:41:

На любом правиле в ipchains есть счетчики пакетов и байтов. Поглядеть их можно ipchains -L -v -x, опция -Z сбрасывает все счетчики в ноль. Т.е. пишете скрипт который разбирает вывод команды ipchains -L -v -n -Z и вперед.

 

Хм, как-то переборщили в Линухе...
в BSD просто ipfw add 3 count ip from 192.168.0.23 to any via rl0
и всё считает.

тут же получается нужно специально делать forward цепочки?
вот у меня например есть
-A forward -s 192.168.4.0/255.255.255.0 -d 192.168.0.0/255.255.255.0 -j ACCEPT
-A forward -s 192.168.0.0/255.255.255.0 -d 192.168.4.0/255.255.255.0 -j ACCEPT

если верить руководству они должны обеспечивать хождение пакетов из 192.168.0.0 в 192.168.4.0 и наоборот. счётчики для них вроде вижу, но непонятно, нужны ли они вообще, и как сделать так, чтобы сеть 192.168.4.0 не видела сети 192.168.0.0 и наоборот?

BrAB, 10.12.2003 15:16:20:

Хм, как-то переборщили в Линухе...
в BSD просто ipfw add 3 count ip from 192.168.0.23 to any via rl0
и всё считает.

 

Не вижу принципиальной разницы.

непонятно, нужны ли они вообще, и как сделать так, чтобы сеть 192.168.4.0 не видела сети 192.168.0.0 и наоборот?

 

"Ты скажи, ты скажи, чё те надо, чё надо..."
Полностью задачу изложите, пожалуйста.

Sokrat, 11.12.2003 09:14:27:

Не вижу принципиальной разницы.

непонятно, нужны ли они вообще, и как сделать так, чтобы сеть 192.168.4.0 не видела сети 192.168.0.0 и наоборот?

 

"Ты скажи, ты скажи, чё те надо, чё надо..."
Полностью задачу изложите, пожалуйста.

 

Уф, косяк.
Вообщем. нужно, чтобы сеть 192.168.4.0 (см. рис) имела доступ в инет (http,ftp,smtp,pop3,icq). При это трафик проходящий на и от ip адресов должен считаться счётчиками выковырить из них значения это не проблема, я на подобной операции на BSD собаку съел (ходя парился долго, попутно изучая Перл).
При этом сеть 192.168.4.0 не должна иметь доступа к 192.168.0.0, т. е. в идеале сети не могкт пинговать и трасировать друг-друга, но главное, они не должны видеть друг друга. Т. е. из одной сети нельзя было бы подключится к манине другой. Сделать это необходимо в целях безопастности, т. к. 192.168.0.0 - это сеть моей организации, а в сети 192.168.4.0 будут сидеть соседи по этажу, которым мы отдаём инет.
Если что нужно - сообщу.
P. S. форум авиабазы единственное место где мне толково ответили.

А почему не поставить ДВЕ подсетки? И объединять их на одной финальной машине, которая будет делать NAT для них обоих?

Ну ipchains это анахронизьм, если линукс то крути iptables это более современная весчь, и в ASP наверняка есть...

BrAB, 11.12.2003 14:27:49:

При этом сеть 192.168.4.0 не должна иметь доступа к 192.168.0.0, т. е. в идеале сети не могкт пинговать и трасировать друг-друга, но главное, они не должны видеть друг друга. Т. е. из одной сети нельзя было бы подключится к манине другой. Сделать это необходимо в целях безопастности, т. к. 192.168.0.0 - это сеть моей организации, а в сети 192.168.4.0 будут сидеть соседи по этажу, которым мы отдаём инет.

 

Это пара правил для iptables/ipchains - надо запретить (дропать) любой траффик с одной сети на другую.
Вот здесь можно найти доки на английском.

BrAB, 11.12.2003 14:27:49:

Вообщем. нужно, чтобы сеть 192.168.4.0 (см. рис) имела доступ в инет (http,ftp,smtp,pop3,icq). При это трафик проходящий на и от ip адресов должен считаться счётчиками выковырить из них значения это не проблема, я на подобной операции на BSD собаку съел (ходя парился долго, попутно изучая Перл).
При этом сеть 192.168.4.0 не должна иметь доступа к 192.168.0.0, т. е. в идеале сети не могкт пинговать и трасировать друг-друга, но главное, они не должны видеть друг друга. Т. е. из одной сети нельзя было бы подключится к манине другой. Сделать это необходимо в целях безопастности, т. к. 192.168.0.0 - это сеть моей организации, а в сети 192.168.4.0 будут сидеть соседи по этажу, которым мы отдаём инет.

 

Ага, теперь понятно. Все, что Вам требуется - 4 правила в цепочке FORWARD:
192.168.4.x -> 192.168.0.x DROP
192.168.0.x -> x.x.x.x DROP
192.168.4.x -> x.x.x.x ACCEPT
x.x.x.x -> 192.168.4.x ACCEPT
И политика по умолчанию DROP.
Траффик снимать, естественно, только с ACCEPT правил. Будьте внимательны к порядку правил.

И, как уже сказали, лучше использовать iptables. Русский перевод весьма подробного туториала. Как прочтете - стоит подтюнить защиту, например, закрыть от врагов INPUT на самом сервере и пропускать в 192.168.4.x только ответные пакеты (ESTABLISHED,RELATED)...

Sokrat, 12.12.2003 00:01:38:

Ага, теперь понятно. Все, что Вам требуется - 4 правила в цепочке FORWARD:
192.168.4.x -> 192.168.0.x DROP
192.168.0.x -> x.x.x.x DROP
192.168.4.x -> x.x.x.x ACCEPT
x.x.x.x -> 192.168.4.x ACCEPT
И политика по умолчанию DROP.
Траффик снимать, естественно, только с ACCEPT правил. Будьте внимательны к порядку правил.

И, как уже сказали, лучше использовать iptables. Русский перевод весьма подробного туториала. Как прочтете - стоит подтюнить защиту, например, закрыть от врагов INPUT на самом сервере и пропускать в 192.168.4.x только ответные пакеты (ESTABLISHED,RELATED)...

 

Я бы еще привязался к интерфейсу, а то умники из 192.168.4.0/24 могут поставить еще и другие адреса. Т.е. с их интерфейса я бы принимал бы только 192.168.4.0/24. Ну и соответсвенно, с вашего интерфейса я бы не разрешал бы ходить другим, чем 192.168.0.0/24.

А насчет пропуска пакетов только ответных - только за.

Mishka, 12.12.2003 02:13:05:

Я бы еще привязался к интерфейсу, а то умники из 192.168.4.0/24 могут поставить еще и другие адреса. Т.е. с их интерфейса я бы принимал бы только 192.168.4.0/24.

 

М-м-м... Не очень понял, о чем Вы, но кажется, что Вы недоглядели - все "умники" попадут в дефалтную политику DROP.

Ну и соответсвенно, с вашего интерфейса я бы не разрешал бы ходить другим, чем 192.168.0.0/24.

 

Этим как раз там делать нечего, по условиям задачи. Или Вы не о FORWARD?

Сижу я на ветке 192.168.4.0 и ставлю себе новый адрес на виртуальном ли интерфейсе или ставлю еще одну карточку - не важно, но адрес 192.168.5.0/24 - и все, по этим правилам, я могу уже достучаться до сети 192.168.0.0/24. Сосуществование разных логических сетей на одном физическом сегменте сейчас вполне возможно. Вот про это я и говорю.

Mishka, 13.12.2003 08:37:33:

Сижу я на ветке 192.168.4.0 и ставлю себе новый адрес на виртуальном ли интерфейсе или ставлю еще одну карточку - не важно, но адрес 192.168.5.0/24 - и все, по этим правилам, я могу уже достучаться до сети 192.168.0.0/24. Сосуществование разных логических сетей на одном физическом сегменте сейчас вполне возможно. Вот про это я и говорю.

 

По моему с теми правилами что написал Сократ, это не пройдет, возможно будет поставить IP из другой сети т.е. 192.168.0.0 в сегменте 192.168.4.0, но это тоже особой пользы не принесет так как раутер будет возврашать ответы на другой интерфейс, думаю так можно будет только сгенерить какой нибудь вредоносный трафик к какому то компьютеру в другой сетке что то типа flood-а на базе пингов днс запросов или еще чего нибудь )
Если у маршрутизатора есть достаточно интерфейсов чтобы привязать отдельные сегменты сети на отдельные интерфейсы, тогда легче всего просто задать в правилах твердо соответствие сеть

П.С. Лучше всего на первой итерации вычистить все файерволы щейпыры и т.д. оставить просто правильную маршрутизацию, как предлагал Сократ и убедится, что все с коммуникациями в порядке, тогда уже "городить огород" с всякими "сложностями" )
т.е. чтото типа:
#iptables -F
#iptables -F -t nat
#
#ifconfig eth0 down
#ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
#ifconfig eth0 down
#ifconfig eth0 192.168.4.1 netmask 255.255.255.0 up

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.0 * 255.255.255.0 U 0 0 0 eth0
192.168.4.0 * 255.255.255.0 U 0 0 0 eth1
#
#echo "1" > /proc/sys/net/ipv4/ip_forward
#

Думаю что этого должно хватить, для перебрасывания пакетов из одной сети в другую
усепх
цеци

Mishka, 13.12.2003 08:37:33:

Сижу я на ветке 192.168.4.0 и ставлю себе новый адрес на виртуальном ли интерфейсе или ставлю еще одну карточку - не важно, но адрес 192.168.5.0/24 - и все, по этим правилам, я могу уже достучаться до сети 192.168.0.0/24.

 

Да ну? А внимательней посмотреть? Ни в одно из 4х правил Вы не попадете - зато попадете в политику по умолчанию и будете дропнуты.

В этой простейшей конфигурации только одна небольшая дырочка (и то она закроется при "пропускать в 192.168.4.x только ответные пакеты (ESTABLISHED,RELATED)") - если в сети 192.168.0.0 кто-то поставит IP 192.168.4.x, то он сможет отправлять пакеты в сеть 192.168.4.0, но назад ему все равно ничего не вернется...

Sokrat, 13.12.2003 13:04:10:

Да ну? А внимательней посмотреть? Ни в одно из 4х правил Вы не попадете - зато попадете в политику по умолчанию и будете дропнуты.

В этой простейшей конфигурации только одна небольшая дырочка (и то она закроется при "пропускать в 192.168.4.x только ответные пакеты (ESTABLISHED,RELATED)") - если в сети 192.168.0.0 кто-то поставит IP 192.168.4.x, то он сможет отправлять пакеты в сеть 192.168.4.0, но назад ему все равно ничего не вернется...

 

Именно это я имел в виду, пользы от такой смены адреса никакой, но для сетки могут появится проблемы. Думаю видел с год назад пример такой атаки на днс услугу, суть была в том что если не отразать частные сети на внешних интерфейсах, злоумышленик может послать заявки к днс /или другому сервизу/ а он в свою очередь перенаправит их по его маршрутизирующей таблице.

хост1 - 192.168.4.20 /ставим на него скажем 192.168.0.20/ -->днс зайвка к днс-у сети->маршрутизатор->днс->днс возвращает ответ к 192.168.0.20-> тут возникает проблемма )) т.к. этот 192.168.0.20 реальный 192.168.0.20 и ему приходится обрабатывать заявки которые он обрабатывать не должен:))

Sokrat, 13.12.2003 13:04:10:

Да ну? А внимательней посмотреть? Ни в одно из 4х правил Вы не попадете - зато попадете в политику по умолчанию и будете дропнуты.

 

Пардон, default policy просмотрел.

Vale, 11.12.2003 17:05:27:

А почему не поставить ДВЕ подсетки? И объединять их на одной финальной машине, которая будет делать NAT для них обоих?

 

Ну... воощем, не смеятся....
Сервер на BSD есть исторически. Трогать его без соответствующей подготовки не охота. поэтому создаётся второй сервер на Linux, который будет и тарификатором и подопытной мышью одновременно. Когда накоплю достаточно экспы для нормального администрирования всего и вся - тогда будет ОДИН сервер.

Pazke, 10.12.2003 11:54:41:

На любом правиле в ipchains есть счетчики пакетов и байтов. Поглядеть их можно ipchains -L -v -x, опция -Z сбрасывает все счетчики в ноль. Т.е. пишете скрипт который разбирает вывод команды ipchains -L -v -n -Z и вперед.

 

Есть проблема: ipchains -L -v не хочет выдавать правила по одному. По номеру - не видит. По имени - перебрал кучу вариантов, так и не нашёл того, которое он примет. Доки прочитал. Всё равно ругается. А ведь можно наверно как-то вывести ОДНО правило.

P. S. если объяснил непонятно. В BSD это делается командой ipfw show 3| например.

BrAB, 15.12.2003 15:24:57:

Есть проблема: ipchains -L -v не хочет выдавать правила по одному. По номеру - не видит. По имени - перебрал кучу вариантов, так и не нашёл того, которое он примет. Доки прочитал. Всё равно ругается. А ведь можно наверно как-то вывести ОДНО правило.

P. S. если объяснил непонятно. В BSD это делается командой ipfw show 3| например.

 

Вот такой он ipchains подлый
Придется вам разбирать все правила скопом.

Pazke, 15.12.2003 15:58:38:

Вот такой он ipchains подлый
Придется вам разбирать все правила скопом.

 

Если бы он такой был бы - разбирал. Но:
-L, --list
              List all rules in the selected chain.

If no chain is selected, all chains are listed.

Т. е. это самое chain можно как-то selected. Об этом же говорит и сократовский мануал. только никто не говорит, как оно должно быть задано.

BrAB, 15.12.2003 17:08:11:

Т. е. это самое chain можно как-то selected.

 

ipchains -L input
к примеру.

Т.е. это вывод набора правил (или как он там правильно обзывается)

BrAB, 15.12.2003 16:08:11:

Т. е. это самое chain можно как-то selected. Об этом же говорит и сократовский мануал. только никто не говорит, как оно должно быть задано.

 

Это о выборе цепочки, а не правила - а цепочка у Вас одна (FORWARD).