sydmund
commented
2 years ago Próbowałem ten schemat zastosować u siebie (Debian 10, kernel 4.19.0-18), ale mam problem...
Kiedyś korzystałem z IMQ, było całkiem OK, ale krótko, bo zapędziłem system w dziury przez brak aktualizacji (patchowanie jest czasochłonne), dlatego przeszedłem na kontrolę ruchu bezpośrednio na interfejsach eth_LAN i eth_WAN, co dało możliwość aktualizacji z repozytoriów. Taki, dość niewyszukany, sposób mi wystarczał. Idzie to tak:
eth0="ens18" #LAN
eth1="ens19" #WAN
# Czyszczenie
tc qdisc del dev $eth0 root 2> /dev/null > /dev/null
tc qdisc del dev $eth1 root 2> /dev/null > /dev/null
# Tworzenie korzenia kolejek $eth0
tc qdisc add dev $eth0 root handle 1:0 hfsc default 100
tc class add dev e$th0 parent 1:0 classid 1:1 hfsc ls m2 550Mbit ul m2 550Mbit
# Tworzenie korzenia kolejek $eth1
tc qdisc add dev $eth1 root handle 1:0 hfsc default 100
tc class add dev $eth1 parent 1:0 classid 1:1 hfsc ls m2 90Mbit ul m2 90Mbit
# Ruch normalny $eth0 i $eth1
tc class add dev $eth0 parent 1:1 classid 1:5 hfsc ls m2 500Mbit ul m2 500Mbit
tc class add dev $eth1 parent 1:1 classid 1:5 hfsc ls m2 90Mbit ul m2 90Mbit
# per IP: 172.21.2.2
tc class add dev $eth0 parent 1:5 classid 1:20 hfsc rt m2 128kbit ls m2 256kbit ul m1 400Mbit d 15s m2 300Mbit #Download
tc qdisc add dev $eth0 parent 1:20 sfq perturb 10
tc filter add dev $eth0 parent 1:0 protocol ip prio 8 u32 match ip dst 172.21.2.2 flowid 1:20
tc class add dev $eth1 parent 1:5 classid 1:20 hfsc rt m2 128kbit ls m2 256kbit ul m1 50Mbit d 15s m2 30Mbit #Upload
tc qdisc add dev $eth1 parent 1:20 sfq perturb 10
tc filter add dev $eth1 parent 1:0 protocol ip prio 8 handle 2122 fw flowid 1:20
I tak dalej dla innych adresów, kończąc classid 1:100 na końcu....Markowanie pakietów via iptables:
iptables -A POSTROUTING -s 172.21.2.2 j MARK ---set-mark 2122
Działało to wedle założeń i z minusami, których byłem świadomy (limitowanie strony LAN) ale jako bramka tylko do Internetu sprawdzała się w porządku. Szczególnie z HFSC byłem zadowolony po przejściu z HTB. Niemniej, jestem zmuszony dodać nową kartę sieciową do strony LAN routera i zaczyna się temat powrotu do wirtualnych interfejsów. Lata lecą, a IMQ w kernelu nie ma, zatem IFB. Jako, że korzystałem z Twoich tekstów wcześniej, bardzo mnie ucieszyło, że i ten temat jest poruszony. Miałem też nadzieję, że w nowym układzie uda się to zrobić nawet bez markowania pakietów w iptables, bo byłoby nieco czyściej przy migracji na nftables. Zatem załadowałem moduły do kernela przy bootowaniu. Tutaj dodam, że bez sch_fq_codel, bo traciłem całkiem kontakt z maszyną. Nie wiem jeszcze czemu, ale ładowany ręcznie po starcie nie robił bałaganu. Niemniej, założyłem, że ten moduł mi nie będzie potrzebny ze względu na pakowanie ruchu do kolejek jedynie po IP i korzystając z linijek tc filter, jak dotychczas. Niestety, cały ruch wpada mi najwyraźniej do klasy domyślnej (kolejka na śmieci i hosty w sieci i tak bez dostępu do Internetu). Nie wiem, czy robię gdzieś błąd i jaki, ale żeby się nie rozpisywać, pokażę swoje linijki:
eth0="ens18" #LAN1
eth1="ens19" #WAN
eth2="ens20" #LAN2
# Czyszczenie
tc qdisc del dev ifb0 root 2> /dev/null > /dev/null
tc qdisc del dev ifb1 root 2> /dev/null > /dev/null
tc qdisc del dev $eth0 root 2> /dev/null > /dev/null
tc qdisc del dev $eth1 root 2> /dev/null > /dev/null
tc qdisc del dev $eth2 root 2> /dev/null > /dev/null
# Przekierowanie ruchu egress
tc qdisc add dev $eth1 root handle 1:0 hfsc
tc filter add dev $eth1 parent 1:0 protocol ip prio 10 u32 match ip dst 0.0.0.0/0 flowid 1:1 action mirred egress redirect dev ifb0
#Przekierowanie ruchu ingress
tc qdisc add dev $eth1 handle ffff: ingress
tc filter add dev $eth1 parent ffff: protocol ip prio 10 u32 match ip src 0.0.0.0/0 flowid 2:1 action mirred egress redirect dev ifb1
#Tworzenie korzenia kolejek
tc qdisc add dev ifb0 root handle 1: hfsc default 100
tc class add dev ifb0 parent 1:0 classid 1:1 hfsc ls m2 550Mbit ul m2 550Mbit
tc qdisc add dev ifb1 root handle 2: hfsc default 100
tc class add dev ifb1 parent 2:0 classid 2:1 hfsc ls m2 90Mbit ul m2 90Mbit
# Ruch normalny ifb0 i ifb1
tc class add dev ifb0 parent 1:1 classid 1:5 hfsc ls m2 500Mbit ul m2 500Mbit
tc class add dev ifb1 parent 2:1 classid 2:5 hfsc ls m2 90Mbit ul m2 90Mbit
tc class add dev ifb0 parent 1:5 classid 1:20 hfsc rt m2 128kbit ls m2 256kbit ul m1 400Mbit d 15s m2 300Mbit #Download
tc qdisc add dev ifb0 parent 1:20 sfq perturb 10
tc filter add dev ifb0 parent 1:0 protocol ip prio 8 u32 match ip dst 172.21.2.2 flowid 1:20
tc class add dev ifb1 parent 2:5 classid 2:20 hfsc rt m2 128kbit ls m2 256kbit ul m1 56Mbit d 15s m2 50Mbit
tc qdisc add dev ifb1 parent 2:20 sfq perturb 10
tc filter add dev ifb1 parent 2:0 protocol ip prio 8 u32 match ip src 172.21.2.2 flowid 1:20
I tak dalej...Jedyna zmiana to wrzucanie do kolejek bez markowania ruchu ulpoad w iptables (u32 match ip src 172.21.2.2), ale próbowałem i po staremu przez handle - to samo. Zresztą, wtedy ingress lub egress działałby OK. Tymczasem, download i upload trafia do kolejki default. Wydaje mi się, że nie pracuje prawidłowo rozdzielanie ruchu po kolejkach per IP.
Dodać jeszcze mogę, że u mnie wyrzuca błąd "Error: Exclusivity flag on, cannot modify" po tc qdisc add dev $eth1 handle ffff: ingress, ale tyle, ile się naszukałem, to można go chyba odpuścić i wynika z jakiegoś buga (https://www.whonix.org/wiki/Dev/latency-obfuscator#Implementation_Details), choć może się mylę, ponieważ komunikat pojawia się też w jakimś kodzie z "sch" w nazwie (https://elixir.bootlin.com/linux/latest/source/net/sched/sch_api.c), a u mnie ładowanie go na starcie powoduje utratę komunikacji z routerem po SSH. Nie wiem natomiast, czy szukać właśnie gdzieś tam, czy może nie ma sensu, skoro w powyższym skrypcie mam błąd, bądź opieram się na błędnych założeniach, że to powinno działać. Będę wdzięczny za opinię.
morfikov
Komentarze dla postu: https://morfikov.github.io/post/konfiguracja-interfejsow-ifb-w-linuxie/