lug-bg: отново за... шейпър
Здравейте,
знам, че тази тема е разисквана мнооого, постарах се да прочета каквото
намерих и направих едно "произведение", но за съжаление не работи коректно.
Та ако някой има малко време бих го помолил да ми каже къде бъркам. И така
става въпрос за една малка мрежа в която трябва да разпределя нет -а по
равно на всички. Ето какво съм направил до тук:
TC=/usr/sbin/tc
#lan interface
dev_lan=eth0
#net interface
dev_inet=eth1
# това е скоростта за теглене (доставчика както може би се сетихте е... бтк)
d_speed=2048
u_speed=512
#броя на потребителите
$users=xxx
$TC qdisc del dev $dev_lan root &>/dev/null
$TC qdisc del dev $dev_inet root &>/dev/null
#root disc
$TC qdisc add dev $dev_lan root handle 1: htb default 1000
$TC qdisc add dev $dev_inet root handle 2: htb default 1001
$TC class add dev $dev_lan parent 1: classid 1:1 htb rate ${d_speed}kbit ceil
${d_speed}kbit
$TC class add dev $dev_inet parent 2: classid 2:1 htb rate ${u_speed}kbit ceil
${u_speed}kbit
#general download class
$TC class add dev $dev_lan parent 1:1 classid 1:2 htb rate
$[$d_speed/$users]kbit ceil ${d_speed}kbit
#general upload class
$TC class add dev $dev_inet parent 2:1 classid 2:2 htb rate
$[$u_speed/$users]kbit ceil ${u_speed}kbit
$TC qdisc add dev $dev_lan parent 1:2 sfq perturb 10
$TC qdisc add dev $dev_inet parent 2:2 sfq perturb 10
От тук нататък съм сложил филтрите които изглеждат по един и същи начин:
$TC filter add dev $dev_lan parent 1: protocol ip prio 1 handle 101 fw classid
1:2
$TC filter add dev $dev_inet parent 2: protocol ip prio 1 handle 1 fw classid
2:2
...
...
$TC class add dev $dev_lan parent 1: classid 1:1000 htb rate
$[$d_speed/$users]Kbps
$TC class add dev $dev_inet parent 2: classid 2:1001 htb rate
$[$u_speed/$users]Kbps
Ето как съм направил маркирането на пакетите (ще покажа само за един
потребител, защото нещата са идентични):
За изходящия трафик:
iptables -t mangle -A FORWARD -s 1.2.3.4 -j MARK --set-mark 1
За теглене:
iptables -t mangle -A POSTROUTING -s ! 1.2.3.4 -d 1.2.3.4 -j MARK --set-mark
102
Ами това е... приемам всякакви съвети и предложения :-)
Благодаря!
Re: lug-bg: Логване на и зходящата поща
Е, mailsnarf е прекалено, dsniff библиотеката е много некадърно написана и може да счупи цялата машина при повечко трафик По-скоро опитай нещо като always_bcc при postfix, макар че и моя хинт е безполезен, тъй като sendmail изглежда няма такава опция :( Въпреки това съм сигурен , че ще стане със дефиниция на rewrite rules. Намери си sendmail administration guide и прочети там как се дефинират local rules. Jordan P. Petkov wrote: Dean Stoeff wrote: За Qmail и Postfix и аз знам как става, другия проблем е, че не мога да сменям архитектурата а също така и да прилагам пачове на самия sendmail Не съм го ползвал, но... mailsnarf ? $apt-cache show dsniff Package: dsniff Priority: extra Description: Various tools to sniff network traffic for cleartext insecurities This package contains several tools to listen to and create network traffic: . * arpspoof - Send out unrequested (and possibly forged) arp replies. * dnsspoof - forge replies to arbitrary DNS address / pointer queries on the Local Area Network. * dsniff - password sniffer for several protocols. * filesnarf - saves selected files sniffed from NFS traffic. * macof - flood the local network with random MAC addresses. * mailsnarf - sniffs mail on the LAN and stores it in mbox format. * msgsnarf - record selected messages from different Instant Messengers. * sshmitm - SSH monkey-in-the-middle. proxies and sniffs SSH traffic. * sshow - SSH traffic analyser * tcpkill - kills specified in-progress TCP connections. * tcpnice - slow down specified TCP connections via "active" traffic shaping. * urlsnarf - output selected URLs sniffed from HTTP traffic in CLF. * webmitm - HTTP / HTTPS monkey-in-the-middle. transparently proxies. * webspy - sends URLs sniffed from a client to your local browser.
Re: lug-bg: Странно поведени на route/linux/rtl8139
Проблема се оправи като сложих картата на друг PCI slot. Очевидно или първоначалният PCI слот е изгорял или не дава допър контакт поради някаква причина и все пак поведението на route в ситуацията ми се вижда странно ;-) Следващият път няма да се ината и понеже проблема го считам за лесен , ами директно ще сменям слота/местоположението на картата :-). В случея не беше спешно нещо, но все пак си поиграх час,два в различни опити и даже смених ядро, защото за миг се осъмних в бъг на драйвера. On 8/25/06, Dimitar Tomow <[EMAIL PROTECTED]> wrote: Не знам дали защото е петък вечер или нещо нямам желание да се занимавам със следният елементарен проблем нещо закучих. Дъно с вгр rtl8139 , за която ядрото (linux) използва 8139too Въпросната мрежова карта изгаря. Слага се втора мрежова на PCI слот пак rtl8139c За нея линукс ядрото зарежда 8139too и 8139cp (?) Аз доколкото знам трябва да е един от двата. Ако е само 8139too eth0 има, ако е само cp не се разпознава картата. 1. Така. Откакто дойде при мен въпросната машина мрежовата беше изгоряла , но бяха забравили да ми кажат. И получавах едно съобщение WATCHDOG transmition timed out за eth0 -> 8139onboard. И мислех че заради това нищо не мога да пратя като Ping и въобще. Изключвах acpi както се препоръчва при такива случей , даже помня и тук преди месец/два имаше тема за WATCHDOG на 8139. Но това съобщение си остана. 2. После като разбрах че картата е изгоряла, нещо което почнах и освен това да подозирам; добавих втората. в този случей eth0 - 8139PCI -> 8139too , 8139cp eth1 -8139onboard -> 8139too only въпреки eth1 down и правилно конф. на eth0 + up, route и всичко да е ок пинг на никъде няма освен към localhost и назначеното статично ip. Съобщението за WATCHDOG не се появаше вече. Викам си картите са еднаква може едната да бърка другата все пак е изгоряла. //Ако се направи опит за dhcp през изгорялат карта системата забива , ясно дава накъсо някъде и при опит за комуникация ... но това е логично и няма отношение към проблема// 3. Та изключих я от биоса вградената, поне доколкото linux вече не я вижда , защот под Windows98 си излизат и двете карти независимо от насстройката в биоса. И сега имам само eth0 -> 8139PCI -> 8139too, 8139cp конф. ifconfig ... обаче ... не добавя сам route към мрежата на картата през нея като интерфейс. Пробвах ръчно route add -net ... netmask ... dev eth0 приема командата route -n нищо, никакви записи и логично "целта недостъпна" Проблема е лесен , знам си ... или втората карта понеже е 1:1 като изгорялата и може би драйвера нещо се шашка, или на ниво биос да се оплита нещо при достъпване адреса на едната крата. /споделят едно irq 11, no i/o адресите естествено са различни и все пак ,дъното мисля беше някакъв dfi с вгр видео sis -> sis chipset и не е кой знае какво. Забравих да кажа и най-очудващото, че при тази 3-тата ситуация само с 8139PCI разрешена и заредна/конфигурирана. Появи се пак това за WATCHDOG-a. Напълно нелогично. Факта е и че не съм пробвал да пускам ядрото с acpi=off, но се съмнявам това да е проблема. По-скоро клоня към това вградената идентична карта, понеже е изгоряла и дава накъсо (или просто неработи) да шашка или модула/драйвра, или биоса , или втората карта ??? Идеи :-) пак казвам усещам , че е нещо тънко и лесно ,ама на :-) пп: варианта за мрежова с различен чипсет е ясен, но в момента нямам , утре е събота, а и ми се иска да е rtl8139 , без някаква специална причина , най-вече пък и защо да се давам на проблема :P Благодаря Ви предварително за отделеното време за този не чак толкова интересен проблем ;-) :-) Също да допълня че rmmod 8139cp за rtl8139PCI нищо не променя. Както казах rmmod 8139too eth0 изчезва като интерфейс.
