Nevite jak snadno se da zmenit zaznam filtru v tc? Ja planuju udelat v siti rekneme roamingovy internetovy pristup, kde kdyz se prihlasis z nejake IP, tak pojedes pres internetovou linku svoji domacnosti. U iptables to zde docilit celkem pohodlne, prectu tabulku s iptablem se zapnutym zobrazenim cisel radku, a potom udelam change.
Problem je, ze kdyz se podivam na vystup tc f show dev imq0, vidim uplne maximalni kulovy. Netusim, podle teho si muzu vybrat pravidlo, ktere bych rad zmenil. Zkouseli jste nekdo menit tu sadu filtru, nebo to vsichni maznete a generujete znova, jak to delam ja? Zatim tam mam akorat fixni zaznam podle domacnosti, kde se filtruje podle fw marku, ktery velmi snadno muzu zmenit. Tridy pridavam vyjimecne, kdezto zmena shapovani jedne IP se muze dit pomerne casteji, a bylo by blby, kdyby se vzdycky na nejakou vterinu vsem zastavil inet, protoze se generuji komplet vsechna pravidla pro tc.
Taky me u shakova prikladu zaujalo, ze tam pouziva prioritu 1. Jak presne se lisi priorita u filtru, a u qdisc? U qdisc to funguje 100%ně, jenom si nejsem jistý, co může dělat priorita u filtru. To jako že je filtr s nižší prioritou kontrolován nějak dřív než ostatní? Funguje to vůbec nějak? S prioritou paketu to asi těžko bude mít něco společného, když se teprve musí určit, kam ten paket patří. Lze tedy prioritizovat pravidla pro filtrování prioritních paketů (ssh, ntp etc) oproti pravidlům pro shapování běžného provozu?
Ja osobně tohle třeba vůbec neřeším. Pokud někdo chce komunikovat po privátní síti, nechť používá privátní IP adresy. Pokud chce někdo používat veřejné, ať si používá. Trochu dvojsečné je to v tom, že dalšímu účastníkovi z tvojí sítě se nepodaří úspěšně připojit na veřejnou jiného ve tvojí síti.
Problém je především v tom, že směruješ obvykle DNAT z jednoho interfacu na ten samý interface. Když jsem se tím naposledy zabýval (momentálně nemáme dost veřejných IP, takže těch pár přidelených není třeba moc řešit), tak celkem spolehlivě fungovalo, že jednak musíš vynechat direktivu příchozího interfacu - dotaz může přijít z inetu i z vnitřní sítě, v obou případech bude obsloužen a přesměrován. Potom v případě, že budeš směrovat iface na ten samý interface zpátky se to kernelu nelíbilo, a nějak to odmítl poslat. Tohle nefungovalo. Aby to fungovalo, bylo potřeba provést SNAT na adresu toho routeru, IP toho odhozího ifacu. Třeba stačilo vypnout jenom rpfilter, nevím, tehdy jsem to tak řešil. Potom to fungovalo. Pro optimalizaci SNATování zpětných adres by asi šlo v mangle tabulce přidat pravidlo na -i interni -o interni -j MARK --set-mark cosi, a potom skočit do SNATu jenom pro ty marky, a udělat SNAT na lokální IP. Jinak by totiž vznikl trojúhelník, kdy žádost by šla přes igw, ale odpověď přímo. A málokterý systém takovou komunikaci povolí
Jestli máte někdo lepší řešení, tak napište.
Jo, jinak k IMQ. Stává se vám taky, že když hodím paket do IMQ přímo z preroutingu, tak mi tcpdump ukazuje každý paket 2x, a to samé ukazuje iptraf? Délá to dost chaos v měření průtoku. Je to normální, nebo jsem nějak zoslil jenom nastavení iptablů a házel to tam 2x?
Mohol by mi prosim niekto popisat, ako mam nastavit uzivatelovi vnutornej siete vonkajsiu IP tak, aby bol nadalej "pod kontrolou" Promethea? Urcite sa to da cez DNAT (pouzivam shorewall), vtedy sa vsetky porty prichadzajuce na danu verejnu IP presmeruju na vnutornu. Problem je v tom, ze tu verejnu IP nemoze mat klient nastavenu na svojom PC. Ak to nastavim cez NAT 1:1, tak ten uzivatel obide vsetky pravidla Promethea. Ako to riesite? Vdaka.
30.11.2006 v 10:40
