При создании класса 1:30 было указано prio 2
у класса 1:2 больше одного потомка, т.е. prio в принципе имеет смысл. А именно (из мануала) The rule is that classes with
higher priority are offered excess bandwidth first.
Что я делаю не так?
Здесь класс 1:30 представляет хост, а :31 и :32 это UDP и TCP в пределах этого хоста.
Задача сделать некоторые хосты с бОльшим приоритетом. Я конечно могу сделать приоритет классов 1:31 и 1:32 больше чем у соответствующих классов остальных хостов, но тогда получается, что prio работает как-бы глобально....
Растолкуйте плиз что к чему
В подвале есть мини-АТС panasonic KX-TD1232, которая подключена к машине под линуксом. Есть программа конфигурации этой мини-АТС, которая работает только под вендой. Хотелось бы иметь программу у себя на компе в офсие и как-то убедить её в том, что АТС подключена к ком-порту виндовс-машины.
Ну или найти программу конфигурации АТС под линукс...но пока мне не удалось этого сделать :(
Может у кого есть идеи как всё это сделать?
Поднял на домашнем роутере прозрачный squid с дефолтовыми настройками(Debian squeeze) кроме размера кеша.
Размер кэша поставил ~2GB, но судя по скорости его заполнения он не очень эффективно используется...многое по ходу пролетает мимо него..
Скоростное гугление показывает, что это из-за того, что многие сайты специально инструктируют сквид не кешировать страницы. Как с этим бороться? Не повлечет ли более агрессивная настройка кеша к нарушению работы сайтов?
Как оптимизировать настройки?
Как лучше отслеживать статистику, чтобы оценить ту самую эффективность?
Вообще канал у меня очень узкий(512кб) на два пользователя, поэтмоу хотелось бы сквида накрутить максимально эффективно.
Устанавливал с минимального CD(debian-6.0.3-i386-businesscard.iso)
В качестве источника пакетов была локальная копия репы(apt-mirror)
apt-mirror выполнил только что прямо перед инсталляцией.
Загрузился с CD, выбирал expert install и выполнил установку в первый раздел (ext3). Есть ещё раздел с LVM, но это к делу не имеет отношения.
Установка прошла успешно. Ядро установлено 2.6.32-5-i486
При загрузке получаю kernel panic not syncing vfs unable to mount root fs on unknown-block 0 0
Проверил grub.conf...всё по уму, через UUID.
добавил ядру rootwait, убрал quiet - получил возможность скроллить консоль и прочитать что нам пишет ядро.
Ничего хорошего оно не пишет.
Ни строки SCSI Subsystem initialized
ни libata version 3.00 loaded
ни упоминаний о pata_via в выводе я не нашел
Вот такая пичалька.
Ума не приложу как так то?
Я бы ещё понял, если бы и с CD инсталлер не обнаруживал контроллер. А так ведь нет - там то он работает!
В общем-то уже года 3 юзаю бездисковый, безвентиляторный роутер на VIA C3 под управлением Devil Linux. Год назад поставил туда в принципе тихий и холодный WD Blue 160GB...В связи с чем хотел влепить туда уже нормальный дистрибутив, но обломался, потому как C3 это уже не i486, но ещё не 586.. какой-то инструкции там нет в общем.. и поэтому лепить туда надо либо чистые i486 бинарники(чего сейчас уже не найти) либо заниматься самосбором(для Devil Linux с этим всё просто было).
В общем есть идея качнуть сорцов Debian'a и собрать minimal install + пара нужных пакетов под C3. Зафигачить где-ниубдь apt-mirror сорцов и по мере надобности пакетики оперативно компилить и инсталить в систему... а чё..нормально..уже хотя-бы дистрибутив, а не from scratch.
Куда копать. Чё-та не нагуглил пока мануалов по сборке всего дистриба.
нужно чтобы UDP пакеты с порта 1194 попадали в класс 1:10
хотел написать
tc filter add dev «${wan_iface}» protocol ip parent 1:0 prio 1 \
u32 match ip sport 1194 0xffff flowid 1:10
но потом прочитал это
ip sport <VALUE> <MASK>
Matches the 16 bit source port in a TCP or UDP IPv4 packet.
This only works if the ip header contains no options. Use the
«link» and «match tcp src» or «match udp src» options if you
can not be sure of that.
Городить тут хэш таблицы не хотелось бы, потому что на интерфейсе будет всего два фильтра.
Хочется попроще как-нибудь...
Мы хотим ограничить скорость входящего трафика, чтобы избежать переполнения очереди у провайдера, который иногда буфферизирует до пяти секунд потока данных. Проблема заключается в том, что на данный момент существует единственный способ это сделать — терять заведомо корректные пакеты. А эти пакеты уже отняли часть полосы пропускания вашего ADSL модема и лишь для того, чтобы быть уничтожеными в надежде, что следующие пакеты будут прибывать с меньшей скоростью. Утерянные пакеты будут переданы повторно. что в конечном счете займет больше полосы пропускания. Когда мы ограничиваем трафик, мы ограничиваем количество пакетов в момент времени допускаемых в нашу сеть. Потому фактическая скорость входящего потока выше, из-за пакетов которые мы уничтожаем. В результате, нам будет необходимо ограничить нашу скорость входящего потока намного ниже, чем действительная скорость ADSL модема чтобы достичь малой задержки. На практике, мне пришлось ограничить мой 1.5Мбит/сек ADSL модем до 700Кбит/сек с тем, чтобы обеспечить приемлемую задержку при пяти одновременных закачках. Чем больше у вас TCP соединений, тем большая часть полосы пропускания будет теряться, и тем ниже вам придется ставить ограничение скорости.
Как же так? Всё реально так плохо? И вообще я что-то смотрю тема именно шейпинга входящего траффика как-то высосана из пальца. Это вообще эффективно хоть в каких-то реальных задачах? Или ограничение скорости обычным дроппером является самым правильным решением?
На сервере будет одна сетевуха(eth0) и я хотел прибить openvpn демоны к 127.0.0.1 а с eth0 форвардить один «публичный» порт(для распределения нагрузки между демонами).
Но DNAT не может перекидывать пакеты на 127.0.0.1
Что в таких случаях делают? Когда одна сетевуха и хочется скрыть сервис?
Тупо фильтровать на INPUTe тоже получается как-то не весело, ибо как отличить пакеты, пробравшиеся прямо с eth0 на конкретный порт и перекинутые по DNAT? Получается маркировать надо, а потом по меткам разбирать.. ерунда всё это...
Также есть в iptables примочка, позволяющая отловить состояние DNAT, но это тоже лишнее правило в и без того нагруженной цепочеке INPUT...
Может какой виртуальный интерфейс поднять тогда? Но тоже вроде как жирно получается, к тому-же даже в случае дргого интерфейса пакеты всё равно могут роутиться на него...
Расклад:
Около 100 клиентов подключены к VPN(openvpn) серверу(Debian) и роутятся(+NAT) через него во внешний мир.
Гоняют они в основном VOIP траффик(skype).
Разумеется, не между собой, а во внешний мир и обратно.
Задача:
Максимально эффективно и поровну распределить имеющуюся полосу(100мбит) Ограничения скорости реализовано на клиентском роутере(в штатном режиме).
Сервер средствами openvpn ограничивает клиенту download в случае если клиент будет взломан(в штатном режиме в это ограничение клиент не упирается никгда).
Т.е. ограничение скорости средствами tc вроде не нужно. Только fair queueing.
Первая мысль:
Наплодить кучу фильтров + столько-же дисциплин SFQ?(по кол-ву клиентов) и всё это туда запихивать по айпишникам...
На сколько это оптимально/правильно?
Как быть с пакетами самого openvpn и пакетами, идущими в/из интернетов.. это всё тоже в SFQ? или сделать их приоритетными..хотя зачем? вот тут тоже немного непонятно..
имеем дело с Debian Live
ФС загрузочного носителя по умолчанию смонтирована(ro) в /live/image
монтирую этот-же раздеел в другую точку монтирования(тоже как ro)
mount -r /dev/sda1 /mnt/mount2
всё OK
теперь делаю
#mount -o remount,rw /mnt/mount2
всё прекрасно! могу писать и пишу.
потом делаю
#umount /mnt/mount2
всё прекрасно!
через время опять хочу смонтировать как ro
#mount -r /dev/sda1 /mnt/mount2
получаю /dev/sda1 already mounted or /mnt/mount2 is busy
ну и подсказку, что mtab намекает, что уже смонтировано в /live/image
при этом 2 важных момента:
1. mount /dev/sda1 /mnt/mount2 прокатывает(заметили. без -r)
2. даже после remount,rw первая точка монтирования всё равно остаётся ro
т.е. выходит, что если я сделал remount,rw а потом umount в следующий раз я должен делать mount уже с попыткой rw а не ro. иначе меня шлют нафиг. так а что, umount не отменяет действия remount.. как-то не понятн пока..почему так?
кстати, аналогично пишет already mounted or busy при попытке сделать mount без -r если до этого не было вызова remount,rw
т.е. монтирование одной ФС в две точки возможно только с одинаковыми параметрами? а remount позволяет типа обмануть эту проверку. или то?
Each open file gets assigned a file descriptor. The file descriptors for stdin, stdout, and stderr are 0, 1, and 2, respectively. For opening additional files, there remain descriptors 3 to 9. It is sometimes useful to assign one of these additional file descriptors to stdin, stdout, or stderr as a temporary duplicate link. [3] This simplifies restoration to normal after complex redirection and reshuffling http://tldp.org/LDP/abs/html/io-redirection.html
Мне абсолютно ясна концепци дескрипторов файлов, стдин, аут и эрр тоже. я не понял насчёт дескрипторов с 3 по 9. которые For opening additional files. растолкуйте плиз.
вот нашел скриптик
#!/bin/bash
# Redirecting stdin using 'exec'.
exec 6<&0 # Link file descriptor #6 with stdin.
# Saves stdin.
~~~~~~покусано~~~~~~
дескриптор 6 - это куда вообще?? тем более, что это начало скрипта. какой файл у нас получил дескриптор 6? ничего не понятно толком...одни догадки только.
Вот допилил debian live(в конфигурации minimal) для роутера.
Стартует это дело с флешки. Работать должно на любом(не старом) компе с двумя сетевухами.
Проблема в том, что иногда(когда сетевухи с разными чипами) имена у них скачут как попало.
И это при том, что МАС у них не меняется между ребутами(читал, что и такое бывает). Просто драйверы грузятся как попало(кстати кто ответит почему?). В логе это видно очень хорошо: то ядро зацепит одну сетевуху, то вторую... ну а что это за роутер у которого WAN интерфейс сегодня в одной дырке, а завтра в другой? )) кароче жЭсть.
Ну была мысль при первом запуске этот самый 70-persistent-net.rules сохранить, а потом подгружать.. но в общем хреть это. ибо задумывалось всё рид онли by design.
Поэкспериментировал немного. работает следующая схема:
1.Загружается система, стартует udev...генерит persistent-net.rules
2.Парсим persistent-net.rules, сортируем имена сетевух по МАС/драйверу/etc..
3.Выгружаем модули сетевух(их имена берутся из persistent-net.rules)
4.Загружаем модули сетевух, ядро генерит события, udev их подхватывает и уже пропускает через подготовленный .rules
5.На выходе имеем воспроизводимый порядок имён сетевух + никакой привязки к конкретному железу(live же всё-таки)
пока эти операции я проводил головой и руками.
мой опыт регулярных выражений ограничивается простенькими grep'ами и шпаргалкой с википедии )
чем бы распарсить это дело и заменить после сортировки NAME?
# PCI device 0x10de:0x0373 (forcedeth)
SUBSYSTEM==«net», ACTION==«add», DRIVERS=="?*", ATTR{address}==«04:4b:80:80:80:03», ATTR{type}==«1», ATTR{ifindex}==«2», KERNEL==«eth*», NAME=«eth0»
каждая сетевуха - одна строка. над ней камент(оттуда название модуля брать надо).
тут уже grep не очень эффективен, кажется..
на чём-то же должны делаться подобные парсеры. весь линух на текстовых конфигах.
После применения правила, маскарадинг срабатывает только для новых соединений. Те соединения, которые успели послать пару пакетиков до применения маскарада(возьмем к примеру даже пинг) - продолжают щимиться в интерфейс без маскарада :(
проверено, что дело сто процентов в conntrack. оно и логично, потому что в первоисточнике написано, что натятся только первые пакеты (т.е. пока state = NEW)
Вот если бы одним разом сбросить состояние всех соединений в NEW..
Видел в интернетах грязный хак: прописать в /proc таймауты conntrack в 0, применить правила, а потом вернуть таймауты на место...
Но я верю, что должен быть более стандартный способ.
На домашнем роутере в данный момент настроен HTB шейпинг в обе стороны(на приём с использованием imq). Фишка ещё в том, что в HTB я активно использую ceil, чтобы скорость не резалась вообще, если активен только один клиент.
Заворачивать HTTP на squid собираюсь прозрачно.
Всё это я уже даже потестил, но мне непонятно как бы при этом сохранить именно HTB шейпер и не использовать сквидовские дэлай-пулы.
Шейпер навешивается на WAN интерфейс(ppp0) ибо скорость LAN сервисов(файлопомойки) ограничиваться не должна.
Проблему вижу в том, что сквид запрашивает странички через WAN «от своего имени»(ip). Тогда я не смогу понять ху из ху и кому сколько подрезать скорости...
Как бы выкрутиться из этой ситуации?
Была мысль, что если пркси не анонимный(а ему таковым быть не обязательно) - то где-то там он таки передаёт адрес клиента, запросившего страницу и в принципе можно было-бы классифицировать пакеты по этому признаку, однако я не знаю как это сделать и можно ли так в принципе.
Ещё думал навесить шейпер на LAN интерфейс, доработав классификацию таким образом, чтобы скорость файлопомойки не резалась...
В общем посоветуйте чё как... может ещё какие-то варианты есть...
1.В «Сетка(10компов)» все компы должны конфигурироваться по DHCP
2.router пробрасывает через инет routed туннель на VPN сервер.
Условия задачи:
1. router должен раздавать адреса по DHCP
2. router не должен делать NAT(т.е. просто заруливает пакеты в туннель)
3. таким образом VPN server будет знать каждую машину из «сетка(10компов)» в лицо. Это необходимое условие.
Вопросы:
1. Очевидно, что VPN сервер должен выдать router'у диапазон адресов, а уже router раздаст их по DHCP всем желающим. Как заставить OpenVPN сервер выделять клиенту не один адрес, а 10 или 100?
Под «выделять» наверное следует понимать РЕЗЕРВИРОВАТЬ.
А в идеальном случае каждому клиенту неплохо было-бы выдавать целую сетку /24
Ну к примеру client1 получает сетку 10.10.10.0/24
client2 10.10.11.0/24 и т.д.
Процесс раздачи роутером DHCP вижу следующим:
1. router установил связь с VPN сервером, получил себе адрес.
2. Скрипт настраивает DHCP сервер, чтобы тот раздавал адреса начиная с полученного от VPN сервара +1 и до конца(оговоренного лимита)...
Ещё вопрос: на каком уровне OSI работает UPnP?
Дело в том, что NAT будет на VPN сервере и хотелось-бы, чтобы UPnP долетали до него.
Собственно, именно поэтому не хочется ещё один NAT на router.
Хочу централизованно всё разруливать на VPN сервере.
Ethernet Bridging через VPN готов рассмотреть только если никак иначе уже не не получается.
Необходимо организовать VPN доступ к сети для ~100 клиентов.
Эти клиенты могут находиться в разных странах, сидеть за NATом и ясное дело, иметь разные айпишники....
В качестве клиентского оборудования нужно выбрать железный ethernet router в пределах $200.
Супер ультра безопасность и мега шифрование не нужны.
В принципе, как я смотрю, PPTP штука удобная и точно работает через NAT, но на сколько хорошо эта «технология» поддерживается в Linux и в железных роутерах? Видел некоторые её типа поддерживают, но чаще натыкаюсь на роутеры с IPSEC VPN(тот же LinkSys, который я очень уважаю), но мне показалось что с IPSEC больше заморочек. Так ли это?
Да, для каждого клиента потребуется шейпинг... но это, я думаю, уже дело техники....
Естественно, было бы круто использовать для всего этого один Linux BOX и не париться.
Что могут сказать более опытные товарищи? На что закладываться? PPTP или IPSEC?
P.S. Блин, похоже IPSEC VPN и на той стороне предполагает реальный IP :(
Вопрос в том, как выбрать оптимальный qlen в зависимости от скорости интерфейса...
У меня дома роутер раздаёт 1мегабит инета трём юзерам..
хочется его оптимально настроить и в глаза бросился тот факт, что на eth стоит qlen 100 а на ppp0 qlen 30
Для шейпинга создаю imq и тут вопрос, какой qlen ему лучше поставить?