Toto je pouze lokální záložní kopie odkazovaného článku, doporučuji navštívit původní odkaz. Připravujete se o případnou plodnou diskuzi pod článkem.
HTB - FAQ
Po delší době tu máme další pokračování článku o HTB. Tentokrát bylo námětem k jeho sepsání množství dotazů, které se mi začalo hromadit v mailu a mne už prostě přestalo bavit odpovídat dokola to samé :-).
Mám v síti jen jednoho sosače, ostatní jsou hodní. Můžu shapovat pouze jeho traffic, nebo musím omezovat i ostatní?
Je samozřejmě nutné nastavit root class pro celé rozhraní a postarat se o to, aby hierarchií tříd prošly VŠECHNY packety (na daném interface samozřejmě). Důvod je docela jednoduchý. Packety, které nezařadíte do nějakého toho qdiscu, samozřejmě přes rozhraní projdou, problémem ale je, že o nich ty ostatní (rozuměj klasifikované) nevědí. Je potom zcela nemožné jakkoliv rozumně regulovat množství packetů, když vlastně ani nevíme, kolik jich je. Odpověď tedy zní: Vytvořte root class s rate 100mbit (event. jiné číslo, které odpovídá maximální šířce pásma) a na tu pověste dvě podtřídy. Jednu pro stahovače, druhou pro ostatní. Jinými slovy, zredukujte příklady uvedené v minulých článcích.
Chtěl bych provozovat shaping na stroji s NATem, ale nefunguje to. Co mám dělat?
Na tuhle otázku už jsem tak trochu alergický. Vždy se totiž dotyčného zeptám: "...a používáte u32 match (tc), nebo markujete packety a potom je teprve klasifikujete (iptables+tc)?". Odpověď vždy bohužel zní: "Jen u32. To vadí?". Už v minulých článcích jsem doporučoval techniku markování packetů. Tehdy jsem upozorňoval na omezené možnosti klasifikování pouze pomocí tc, a tohle je jeden z ukázkových příkladů. Kde je tedy problém? Na NATovací stroj přijdou packety z vnitřní sítě, ten je vezme, přepíše jejich původní zdrojovou adresu na adresu svého vlastního vnějšího interface (protože ta původní je z neveřejného rozsahu) a pošle je do světa. Celá zeměkoule si pak myslí, že packet pochází od routeru a o nějakých počítačích za ním nemá ani ponětí. Když dorazí odpověď, NATovač ví, že nepatří jemu osobně, ale jedné z jeho oveček, a tak cílovou adresu takového packetu tentokrát přepíše na (neveřejnou) IP svého "klienta" a pošle ho do vnitřní sítě. Problémem je, že rozdělování do jednotlivých tříd probíhá v okamžiku těsně před odesláním na daném interface (v našem případě máme problém na vnějším). Podle čeho máme totiž poznat, od koho packet skutečně přišel, když už má dávno přepsanou svoji zdrojovou adresu? "Běžnými" prostředky to nejde, a tak nám nezbývá, než přidat někam do packetu informaci, která se při překladu adresy neztratí, a ještě ke všemu tak musíme učinit v době právě před překladem. Přesně z tohoto důvodu jsem tehdy doporučoval iptables a target MARK. Není totiž nic jednoduššího než přidat primitivní pravidlo někam do FORWARD, tedy ještě bezpečně před překladem, a vše je magický zařízeno. Opět řečeno jinak, držte se mých ukázek.
Chci udělat shaping podle vašeho návodu, ale s tím vylepšením, že bude rozlišovat jistá "časová pásma" a např. v nočních hodinách bude benevolentnější co se týče limitů. Jak na to?
Na tuto otázku se mi odpovídá docela snadno. Udělejte skript pro denní a noční režim a pak zkuste "man cron"...
Vás skript běhá dobře, ale když překročím magickou hranici deseti uživatelů, hází to chyby a nefunguje. Co s tím?
Skripty, které jsem v minulých dílech přiložil, měly samozřejmě sloužit jen coby jakýsi návod k tomu, jak si napsat vlastní a lepší. Zdá se ale, že někteří čtenáři nemají dostatek schopností nebo snad nálady, aby tak učinili, a tak se tento dotaz vyskytuje poměrně často. Není ale důvod se na někoho kvůli tomu zlobit, a tak přikládám upgrade problematického skriptu s několikanásobně širšími limity. Limit pro počet bandů je 9 (beze změny). Vše by šlo samozřejmě rozšířit ještě více, ale to už nechám na vás. Hint: ID třídy je složeno z hexadecimálních (tedy ne pouze dekadických) čísel...
Tímto jsem odpověděl na ty nejčastější dotazy a pevně doufám, že tím značně omezím počet mailů k tomuto tématu. Hlavně to neberte jakkoliv negativně, vždy rád s nějakým problémem pomohu, jen na to zkrátka nemám příliš mnoho času...