handler

Здравствуйте! os - Fedora 10 Гигабитная сетевая карта - D'link 528T Ставим карточку, включаем машину, смотрим логи: /var/log/messages dmesg lspci lsusb пусто Вставляем кабель - лампочки загорелись. вышеуказанные команды опять ни байта намека на карточку. Вставялем установочный диск и читаем инструкцию по установки модуля для линукса: Просят распаковать архив - а самого архива нет, ну и не надо, зато есть файл исходник. Собираем его: make - сразу же выдает ошибку в исходниках ядра. Идем на фтп производителя, качаем оттуда исходники, собираем - ошибки те же. Причем, указано, что модуль собирается для 2.2 и 2.4, для 2.6 вроде встроен в ядро. смотрим lsmod - есть 8129. Тогда почему карточка не определяется? Кто-нибудь ставил длинковские гигабитные карточки на линукс?

Хорошо, но мне необходимо фильтровать трафик по адресам, и не важно, в дефолтный класс они будут заворачиваться или нет - нужно создать столько очередей, сколько абонентов и заворачивать каждого отдельно... Кроме как в цикле этого не реализуешь, а собрать netfilter с поддержкой IPMARK мне не удалось

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

так все пользователи будут в одном канале - как селедки в бочке... Похоже на ситуацию без шейпера совсем. А если использовать сквид - он способен разделять тип трафика по приоритетам? К примеру, чтобы скайп и аська имели более высокий приоритет, а фтп и торрент - более низкий?

так все пользователи будут в одном канале - как селедки в бочке... Похоже на ситуацию без шейпера совсем

Хорошая мысль - попробую

Спасибо - уже читаю

Здравствуйте! Задача орининальна: При в ходе в систему (будь то линукс или виндовс)на любой машине в локальной сети проходить авторизацию на сервере (линукс) и монтирование на клиенте двух дисков с сервера: диск с квотами (рабочее пространство пользователя) Диск с ПО пользователя Какие есть идеи?

Здравствуйте! Нужно написать один набор правил для всех адресов в сети для ограничения входящего трафика вместо сотен таких для каждого адреса #tc qdisc add dev eth0 root handle 1: htb #tc class add dev eth0 parent 1: classid 1:1 htb rate 250kbps burst 10kbps #tc class add dev eth0 parent 1:1 classid 1:10 htb rate 16kbps ceil 250kbps burst 2kbps #tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.1 flowid 1:10 Есть решения?

IF_PPP - ppp+ NET_PPP - впн-подсеть (100.100.100.0/24 у меня, например) IF_LOCAL - eth0 (интерфейс в локальную сеть) DHCP_NET - у меня адреса в сети раздаются по dhcp - адреса локальной сети (у меня 192.168.0.0/16) IF_PR1 - интерфейс наружный (eth1) IP_PR1 - адрес наружного интерфейса ${FW} -A INPUT -i $IF_PPP -s $NET_PPP -j ACCEPT ${FW} -A INPUT -i $IF_LOCAL -s $DHCP_NET -p gre -j ACCEPT Главное правило, пропускать пакеты для установления соединения ${FW} -A INPUT -i $IF_LOCAL -s $DHCP_NET -p tcp --dport 1723 -j ACCEPT ${FW} -A OUTPUT -o $IF_PPP -d $NET_PPP -j ACCEPT ${FW} -A OUTPUT -o $IF_LOCAL -d $DHCP_NET -p gre -j ACCEPT ${FW} -A OUTPUT -o $IF_LOCAL -d $DHCP_NET -p tcp --sport 1723 -j ACCEPT ${FW} -A OUTPUT -o $IF_LOCAL -d $DHCP_NET -p udp --sport 1723 -j ACCEPT ${FW} -A FORWARD -i $IF_PPP -s $NET_PPP -d 0/0 -j ACCEPT ${FW} -A FORWARD -s 0/0 -d $NET_PPP -o $IF_PPP -m state --state ESTABLISHED,RELATED -j ACCEPT Для каждой цепочки (INPUT, OUTPUT, FORWARD) поставить правила в начала или вместо "A" ставить "I" Не забудь NAT: ${FW} -t nat -A POSTROUTING -s $NET_PPP -o $IF_PR1 -j SNAT --to-source $IP_PR1

с этого момента по-подробнее! У меня локальный интерфейс eth0 192.168.1.1/16 и на него я повесил впн-сервер 100.100.100.1/24. ВПН-туннели создаются, но в нет не пускает. А Вы предлагаете на eth0 cоздать влан eth0.10 200.200.200.1/24 и на него повесить впн-сервер? И что тогда, какие у нас преимущества?

Здравствуйте! имеем роутер на базе Fedora10 + eth0 - локальная сеть eth1-eth4 - подключены к адсл-модемам Описаны 4 таблицы маршрутизации для 4 интерфейсов и пакеты маркируются 4-мя метками для роутинга на внешние интерфейсы - вобщем, до сих пор все как по учебнику. Теперь мы создаем vpn-туннели на локальном интерфейсе и прописываем для них правила в iptables: эти строки необходимы для создания vpn-туннеля: #${FW} -A INPUT -i $IF_PPP -s $NET_PPP -j ACCEPT #${FW} -A INPUT -i $IF_LOCAL -s $DHCP_NET -p gre -j ACCEPT #${FW} -A INPUT -i $IF_LOCAL -s $DHCP_NET -p tcp --dport 1723 -j ACCEPT #${FW} -A INPUT -i $IF_LOCAL -s $DHCP_NET -p udp --dport 1723 -j ACCEPT #${FW} -A OUTPUT -o $IF_PPP -d $NET_PPP -j ACCEPT #${FW} -A OUTPUT -o $IF_LOCAL -d $DHCP_NET -p gre -j ACCEPT #${FW} -A OUTPUT -o $IF_LOCAL -d $DHCP_NET -p tcp --sport 1723 -j ACCEPT #${FW} -A OUTPUT -o $IF_LOCAL -d $DHCP_NET -p udp --sport 1723 -j ACCEPT Собственно, форвардинг: #${FW} -A FORWARD -i $IF_PPP -s $NET_PPP -d 0/0 -j ACCEPT #${FW} -A FORWARD -s 0/0 -d $NET_PPP -m state --state ESTABLISHED,RELATED -j ACCEPT И НАТ: #${FW} -t nat -A POSTROUTING -s $NET_PPP -j SNAT --to-source $IP_PR1 Получаем интересную картину: сам ppp-сервер пингуется; сами адсл-модемы пингуются; адреса eth1-eth4 и адреса в интернет НЕ пингуются. /etc/ppp/options.pptpd поставил опцию "noproxyarp", а то при создании туннеля пишет "Cannot determine proxy arp" Вывод каких команд Вам показать, чтобы иметь полную картину происходящего?

Вот именно - БОЛЬШИНСТВО! Федора не последовала Вашему замечанию, более того, даже на офф ховто не удосужилась рассказать о назначении файлов в директории /etc/modprobe.d, и в манах ничего - все по-старому: modules.conf и т. д. К стати, lm_sensors и требуют модуль coretemp, пока запускал его вручную, теперь прописал в /etc/rc.local - пока не перезагружался, после проверю. Спасибо...

у меня нет файла /etc/modprobe.conf Спаибо за советы - обязательно попробую оба варианта. Странно то, что в этом дистре они изменили привычную схему загрузки модулей - раньше все просто было, вот я и пошел старым проверенным путем, а он уже не работает. Это что же получается, теперь модули грузятся ч/з ж...? Странно, в линуксах всегда порядок был: мухи отдельно, котлеты отдельно...

rate - скорость ровно как надо и ceil - скорость сколько можно дать, если канал не занят,должны совпадать

Прошу Вас в очередной раз показать мне мою несостоятельность! Задача: загружать модуль coretemp для отображения датчиков температуры процессора на рабочем столе. ОС - Fedora10. Ну, это просто: modprobe coretemp - но это же ручками набирать надо, а для автоматической загрузки нашел /etc/modprobe.d/modprobe.conf.dist Там пишу: alias coretemp coretemp - не помогло install coretemp /bin/true install coretemp /sbin/modprobe --iggnore-install После этих команд даже modprobe не грузит Что самое интересное, нигде не нашел описания загрузки модулей (есть только modprobe.conf)

Здравствуйте господа! Имеем: роутер на базе fedora10 с 5 внешними линками (адсл-модемы) и одним внутренним в локальную сеть. Суть проблемы в следующем: пользователи внутренней сети постоянно жалуются, что интернет часто пропадает, т. е. имеют место разрывы связи, ч/з некоторый промежуток времени все восстанавливается. И тут я недавно наткнулся на статью про похожие траблы http://www.opennet.ru/base/net/pppoe_mtu.txt.html . Посмотрел MTU у себя и обнаружил такую картину (думаю, Вы догадываетесь, какую): на всех интерфейсах роутера (внутренний и внешние), а также на интерфейсах клиентов влокальной сети mtu=1500 (по умолчанию), а на самих дсл-модемах - 1492. Теперь, собственно, вопрос: Нам необходимо и достаточно установить значение mtu на всех интерфейсах роутера 1492, или также необходимо указать iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu ? Если у меня mtu адсл-модемов 1492, значит мне необходимо изменить mtu на 1492 только тех интерфейсов, которые смотрят на модемы, а размер mtu локального интерфейса оставить 1500 для нормальной работы с клиентами? Далее tcpdump показал, что флаг DF установлен на всех пакетах(99% вероятности, я не могу просмотреть весь дамп), приходящих с локального интерфейса, и флаг NONE на пакетах, которые приходят из-вне в локалку. В статье написано: Enable PMTU clamping via IPTABLES This solution is only modern 2.4.x kernel users connected via ANY type of Internet connection. This solution allows for changes to be done ONLY on the MASQ server itself and not on all of the internal MASQ clients. iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu Т. е. мне достаточно добавить одно правило и проблема будет решена беизменения значений mtu ?

Немного изменил конфигурацию: eth0 - 200.200.200.1/24 - смотрит в локальную сеть eth1 - 10.10.10.10/24 - смотрит на адсл-модем правила iptables: FW='/usr/sbin/iptables' IF_LOCAL='eth0' IP_LOCAL='200.200.200.1' NET_LOCAL='200.200.200.0/24' IF_NET='eth1' IP_NET='10.10.10.10' NET_NET='10.10.10.0/24' IF_PPP='ppp+' PPP_NET='100.100.100.0/24' IP_GW1='10.10.10.1' EXT_NET='0/0' echo 1 > /proc/sys/net/ipv4/ip_forward route add default gw $IP_GW1 $FW -F $FW -X $FW -Z $FW -t nat -F $FW -t mangle -F # ************ INPUT ***************************** $FW -A INPUT -i lo -j ACCEPT $FW -A INPUT -i $IF_PPP -j ACCEPT $FW -A INPUT -i $IF_LOCAL -s $PPP_NET -j ACCEPT $FW -A INPUT -i $IF_LOCAL -s $NET_LOCAL -p tcp --dport 1723 -j ACCEPT $FW -A INPUT -i $IF_LOCAL -s $NET_LOCAL -p udp --dport 1723 -j ACCEPT $FW -A INPUT -i $IF_LOCAL -s $NET_LOCAL -p gre -j ACCEPT $FW -A INPUT -i $IF_LOCAL -j DROP # ************ OUTPUT ***************************** $FW -A OUTPUT -o lo -j ACCEPT $FW -A OUTPUT -o $IF_PPP -j ACCEPT #$FW -A OUTPUT -o $IF_LOCAL -d $PPP_NET -j ACCEPT $FW -A OUTPUT -o $IF_LOCAL -d $NET_LOCAL -p tcp --sport 1723 -j ACCEPT $FW -A OUTPUT -o $IF_LOCAL -d $NET_LOCAL -p udp --sport 1723 -j ACCEPT $FW -A OUTPUT -o $IF_LOCAL -d $NET_LOCAL -p gre -j ACCEPT $FW -A OUTPUT -o $IF_LOCAL -j DROP # ************ FORWARD ***************************** $FW -A FORWARD -i $IF_PPP -d $EXT_NET -j ACCEPT $FW -A FORWARD -s $EXT_NET -d $PPP_NET -j ACCEPT # ************ POSTROUTING ***************************** $FW -t nat -A POSTROUTING -s $PPP_NET -d $EXT_NET -j SNAT --to-source $IP_GW1 [/codebox] iptables-save # Generated by iptables-save v1.3.6 on Tue Sep 15 09:38:29 2009 *mangle :PREROUTING ACCEPT [392:27906] :INPUT ACCEPT [383:27310] :FORWARD ACCEPT [9:596] :OUTPUT ACCEPT [288:20286] :POSTROUTING ACCEPT [235:16202] COMMIT # Completed on Tue Sep 15 09:38:29 2009 # Generated by iptables-save v1.3.6 on Tue Sep 15 09:38:29 2009 *nat :PREROUTING ACCEPT [128:11077] :POSTROUTING ACCEPT [11:836] :OUTPUT ACCEPT [7:552] -A POSTROUTING -s 100.100.100.0/255.255.255.0 -j SNAT --to-source 10.10.10.1 COMMIT # Completed on Tue Sep 15 09:38:29 2009 # Generated by iptables-save v1.3.6 on Tue Sep 15 09:38:29 2009 *filter :INPUT ACCEPT [3:252] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [9:756] -A INPUT -i lo -j ACCEPT -A INPUT -i ppp+ -j ACCEPT -A INPUT -s 100.100.100.0/255.255.255.0 -i eth0 -j ACCEPT -A INPUT -s 200.200.200.0/255.255.255.0 -i eth0 -p tcp -m tcp --dport 1723 -j ACCEPT -A INPUT -s 200.200.200.0/255.255.255.0 -i eth0 -p udp -m udp --dport 1723 -j ACCEPT -A INPUT -s 200.200.200.0/255.255.255.0 -i eth0 -p gre -j ACCEPT -A INPUT -i eth0 -j DROP -A FORWARD -i ppp+ -j ACCEPT -A FORWARD -d 100.100.100.0/255.255.255.0 -j ACCEPT -A OUTPUT -o lo -j ACCEPT -A OUTPUT -o ppp+ -j ACCEPT -A OUTPUT -d 200.200.200.0/255.255.255.0 -o eth0 -p tcp -m tcp --sport 1723 -j ACCEPT -A OUTPUT -d 200.200.200.0/255.255.255.0 -o eth0 -p udp -m udp --sport 1723 -j ACCEPT -A OUTPUT -d 200.200.200.0/255.255.255.0 -o eth0 -p gre -j ACCEPT -A OUTPUT -o eth0 -j DROP COMMIT # Completed on Tue Sep 15 09:38:29 2009 [/codebox] Идея проста: dhcpd раздает адреса клиентам в сети из диапазона 200.200.200.10-250 Далее клиент создает ppp-туннель, получая адрес из диапазона 100.100.100.10-250 Правила INPUT OUTPUT работают, как требуется: ограничивают доступ по eth0 только для установления ppp-соединения, а для ppp-туннелей разрешают. Не работает только FORWARD POSTROUTING - с клиента не пингуется ни eth0(10.10.10.10), ни адсл(10.10.10.1)

Ок. попробую. Спасибо.

Интересный вариант - я о таким и не подумал. Но вот в чем загвоздка: у меня диапазон 192.168.1.2 - 192.168.250.250. В этом диапазоне находятся адреса машин в настоящее время ( на каждой машине прописан свой адрес). Теперь я пытаюсь постепенно все машины перевести на раздачу адресов с сервера. сегодня это может быть машина с адресом 2.100 а завтра - 200.5 Вот и получается, что я не могу провести четкую границу диапазона адресов. А насчет того что адреса в range не должны совпадать с host - я не знал. Спасибо за подсказку.

И Вы снова правы! НО! Изначально я объявил range 192.168.0.0/16 и прописал только один host 192.168.1.1 - в целях испытания; машина нормально получала адрес и работала. Со временем появилась необходимость предоставить адрес еще одной машине - мы добавили строку host 192.168.1.2; и не получили ожидаемого результата. Так продолжалось некоторое время, пока, в очередной раз, при назначении адреса машине я увидел, что машина получила адрес, отличный от указанного. Я удивился: как она могла получить, к примеру 192.168.10.10 если я в host прописал 192.168.20.20 ? Поиски привели к dhcpd.leases, в котором я нашел запись с хостом 192.168.10.10 уже используется. Тогда я понял, что сервер раздает адреса из диапазона 192.168.0.0/16 ВСЕМ МАШИНАМ В СЕТИ!(которые настроены на автоматическое получение адреса) Я начал искать в манах, как указать серверу раздавать только конкретные адреса только конкретным машинам и нашел такую конструкцию с перекрытием диапазонов адресов. Сервер предупреждает о совпадении диапазонов адресов, но реагирует адекватно и при данной схеме адреса получают те маштны, которым они предназначены. Если у вас имеется другая схема назначения адресов только делегированным машинам - прошу пример в студию. Иначе прошу Вас дать мне ответ: может ли машина с мак-адресом, отличным от заявленного, получить адрес? Судя по файлу лиасов так оно и есть, но почему?

В вышеуказанном примере все переменные уникальны - так что путаницы возникнуть не должно. Вы правы - подсеть состоит из одного адреса. Это сделано в целях предотвращения использования зарезервированных адресов. Если, к примеру, мы хотим выделить еще один адрес для другой машины в сети, то мы объявляем еще одну такую же подсеть 192.168.0.0/16 и прописываем в ней нужный хост. Если же мы будем применять общую схему раздачи адресов, то, вполне вероятно, адрес, который мы назначим одной из машин, будет уже назначен другой машине в сети (сеть 100 клиентов), и его запись будет в файле лиасов.

Здравствуйте! Имеем роутер на базе fedora10 c dhcpd-сервером dhcpd.conf authoritative; option domain-name-servers 192.168.1.1; option routers 192.168.1.1; subnet 192.168.0.0 netmask 255.255.0.0 { range 192.168.x.y; host mag { hardware ethernet 11:22:33:44:55:66; fixed-address 192.168.x.y; } } dhcpd.leases lease 192.168.x.y { starts 3 2009/09/02 12:33:52; ends 3 2009/09/02 12:33:52; cltt 3 2009/09/02 12:33:52; binding state abandoned; next binding state free; } lease 192.168.x.y { starts 3 2009/09/02 12:33:53; ends 3 2009/09/02 12:35:53; cltt 3 2009/09/02 12:33:53; binding state free; hardware ethernet aa:bb:cc:dd:ee:ff; uid ""; } /var/log/messages Sep 2 15:33:52 server dhcpd: Abandoning IP address 192.168.x.y: pinged before offer Sep 2 15:33:52 server dhcpd: Wrote 0 deleted host decls to leases file. Sep 2 15:33:52 server dhcpd: Wrote 0 new dynamic host decls to leases file. Sep 2 15:33:52 server dhcpd: Wrote 1 leases to leases file. Sep 2 15:33:53 server dhcpd: Reclaiming abandoned lease 192.168.x.y. Sep 2 15:33:53 server dhcpd: DHCPDISCOVER from aa:bb:cc:dd:ee:ff via eth0 Sep 2 15:33:53 server dhcpd: DHCPOFFER on 192.168.x.y to aa:bb:cc:dd:ee:ff via eth0 Это что значит - адрес был назначен машине с другим мак-адресом? Клиент с нужным мак-адресом получает назначенный ему адрес и работает под ним, видимо, после закрытия сессии он освобождает его и сервер назначает его другому. Сервер раздает около 10 адресов, но проблема только с одним-двумя. Может, я не правильно толкую значение логов и лиасов?

EvilShadow писал(а) Wed, 26 August 2009 17:51 Лично мне для понимания этого понадобилось удалить целиком таблицу разделов, потеряв таким образом содержимое винта Насколько мне помнится, MBR хранится где-то еще на нулевой дорожке - надо почитать мануал к фат-32

Здравствуйте! Рано или поздно использование команды "rm" приводит к серьезным потерям и приходится изучать приемы восстановления данных. Так вот, удалил я один раздел файловой системы, который соответствует жесткому диску /dev/sda1 - 320G (Часть файлов ~200G удалить не успел - вовремя опомнился). Сначала отмонтировал его, далее по мануалу http://www.faqs.org/docs/Linux-mini/Ext2fs-Undeletion.html Траблы начались с e2fsck, когда она отказалась восстанавливать суперблоки (сделал даже mkfs -t ext2 -n /dev/sda1 т. е. в "dry mode" - так она показала резервные суперблоки данного раздела). Дальше отказался работать debugfs (вывод обоих команд предоставить не могу, т. к. переутсановил раздел заново - благо резервная копия была месячной давности), и я отказался от дальнейших попыток. Теперь думаю снять образ с системного диска командой dd(dd if=/dev/sdb of=/dev/sdc1 bs=4K count=0), только вот думаю, можнно ли снимать образ с диска, на котором работает система, а отмонтировать его нельзя. А какие приемы восстановления файловой системы знаете Вы? Для примера возьмем команду "rm -rf /"