Opisany przeze mnie kiedyś traffic shaping na Linuksie troszkę mi się skomplikował - z powodu podłączenia drugiej sieci LAN/WiFi do routera jako “hotspota”. Przy kształtowaniu ruchu pojawiła się zatem potrzeba klasyfikowania pakietów również po interfejsie. Wykonalne jak najbardziej… ale połowę zachodu psuje sam SQUID.

Hotspot w tym przypadku to jakiś tani AP podłączony do kolejnej sieciówki i tym samym bardzo ładnie odseparowany fizycznie od wewnętrznej sieci naszego laboratorium. Router ma zatem dwa interfejsy LAN i jeden WAN, na którym kształtowany jest ruch wyjściowy.

Interfejs lokalny “hotspot” ma mieć ścisłe ograniczenie transferu (20% łącza wychodzącego), by podłączone tam ludki nie czuły się zbyt swobodnie. Niestety nie da się skonstruować filtrów dla tc na interfejsie WAN odwołujących się np. do adresu źródłowego z LAN-u czy do nazwy samego interfejsu - przeszkadza tu NAT, bo pakieciki są przepisywane.

Da się to rozwiązać oznaczaniem (”mark“) ruchu, np. coś w stylu:

iptables -t mangle -A PREROUTING -i $LAN_HOTSPOT -j MARK --set-mark 0x1

Teraz utworzenie filtru dla tc jest banalne, np.:

tc filter add dev $WAN parent 1:0 protocol ip prio 1 handle 0x1 fw flowid 1:13

Komunikacja po FTP, POP itd. ładnie się kolejkuje do klasy “hotspot”. Ale przy HTTP… zonk! Pakiety na port HTTP są oznaczane, ale filtr “nie trafia” w nie. Czemu? Bo mu na drodze stoi wredny SQUID, a właściwie reguła dla iptables:

iptables -t nat -A PREROUTING -i $LAN_HOTSPOT \
-p TCP --dport 80 -j REDIRECT --to-port 3128

Czyli wszystkie pakiety na HTTP nie polecą do NAT-u, a później w świat, ale zostaną przepisane, by ich adresatem docelowym był localhost:3128. Tam siedzi SQUID, który nie forwarduje tak otrzymanych pakietów, ale tworzy nowe, własne. Tym samym życie pakietu się urywa, a wraz z nim znika nasz “mark 0×1″.

Rozwiązanie? Cały ruch wychodzący ze SQUID-a oznaczać “0×1″? Nie, bo oznaczymy ruch z każdego interfejsu. Wyłączyć SQUID-a na interfejsie hotspot? Nie, bo zniknie kontrola…

Wyjściem z sytuacji jest pobawienie się TOS-em lub DSCP na poziomie SQUID-a. Dokładniej:

1. W konfiguracji SQUID-a utworzyć regułę ACL dla sieci “hotspot”, np.:
   acl hotspot src 192.168.4.0/24
2. Następnie nadać TOS/DSCP dla połączeń związanych z tym ACL-em:
   tcp_outgoing_dscp 0x08 hotspot
3. Powyższa instrukcja wymaga wyłączenia:
   server_persistent_connections off
4. Teraz tylko w firewallu dodatkowa reguła oznaczająca pakiety:
   iptables -t mangle -A OUTPUT -p TCP --dport 80 \
-m tos --tos 0x08 -j MARK --set-mark 0x1

I już - hotspot ma ścisłe limity :).