Az előző részben alapszinten megvizsgáltuk, hogyan tudunk az OpenBSD pf segítségével NAT-olni ill. portátirányítást beállítani. A pf tudása azonban tartogat még számunkra érdekes lehetőségeket. Ugyanis ha az előzőekben áttekintett funkciókat alkalmazva már sikerült beállítanunk a más hálózatokra irányuló címfordítást és a csomagszűrő segítségével biztonságossá is tettük ezt, megtehetjük, hogy a rendelkezésre álló sávszélességet minél gazdaságosabban használjuk ki. Erre lesz alkalmas a pf traffic shaper-e, az ALTQ (Alternate Queueing).
OpenBSD tűzfal (pf) – III. rész – traffic shaping (queueing)
Ahhoz, hogy a pf tűzfalunk alkalmas legyen sávszélesség-szabályozásra ill. forgalom priorizálásra, az operációs rendszerünknek ezt kernel szinten is támogatnia kell, ellenkező esetben a pf.conf betöltésekor a queue szabályokhoz érve hibaüzenetet kapunk, hogy nem támogatja ezt kernelünk. A kernel újrafordítására nem fogok most részletesen kitérni, a jelenleg használt OpenBSD 5.1 amúgy is tartalmazza már a megfelelő modulokat, tehát itt csak annyit jegyzek le, mely opciók lennének szükségesek (a kernel konfigok i386 architektúra esetén a /usr/src/sys/arch/i386/conf/GENERIC útvonalon találhatók):
options ALTQ
options ALTQ_CBQ # Class Based Queuing (CBQ)
options ALTQ_RED # Random Early Detection (RED)
options ALTQ_RIO # RED In/Out
options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC)
options ALTQ_PRIQ # Priority Queuing (PRIQ)
options ALTQ_NOPCC # Required for SMP build
Nézzük tehát, hogy a konfigurációban mire van szükségünk ahhoz, hogy megvalósuljon a sávszélesség szabályzás. Szerkesszük meg az /etc/pf.conf filet, és adjuk hozzá a következőket:
Az ALTQ tehát egy mondatban megfogalmazva azt teszi, hogy deklarál egy vagy több queue-t, majd normál, már látott filterszabályokkal ezekre hivatkozik. Nézzük sorra, mely sor vagy sorok mit eredményeznek!
altq on em0 cbq bandwidth 8Mb queue { www, ftp, other }
Ez a sor aktiválja az ALTQ modult az em0 interfacen-n, Class Based Queue módban. Ez lesz a parent queue. A maximális sávszélességet, amiből gazdálkodni foguk, 8Mb/s-ben határozza meg, és három child queuet, a www, az ftp, és az other queue nevez meg.
queue www bandwidth 1% priority 2 cbq
queue ftp bandwidth 50Kb priority 5 cbq
queue other bandwidth 2Mb priority 7 cbq(default)
A fentebbi három sor írja le a child queuekat. A ’www’ nevű használhatja a sávszélesség 1%-át, és 2-es prioritása van. Itt megjegyezhetjük, hogy az ALTQ rendelkezik QoS (Quality of Service) képességekkel is, tehát a forgalom sávszélességét nemcsak szabályozhatjuk, de priorizálhatjuk is. Ez azt jelenti, hogy a ’www’ queueba eső forgalom ugyan csak a sávszélesség 1%-át fogja használni, de ha egyszerre van jelen más forgalom is, akkor ennek lesz a legnagyobb a prioritása. Az ’ftp’ queue sávszélessége abszolút módon van megadva, ez 50Kb/s. Az ’other’ queue, ami a mi esetükben minden más, az előző kettőtől eltérő forgalmat jelenti majd, 2Mb/s sávszélességet kap. Fontos, hogy egy default queue-nak léteznie kell.
pass out quick on em0 inet proto tcp to port { 20, 21 } flags any queue ftp keep state
pass out quick on em0 inet proto tcp to port 80 flags any queue www keep state
pass out on em0 all queue other keep state
Az utolsó három sor a létrehozott queuekat párosítja a megfelelő forgalommal. Láthatjuk, hogy ezek mezei csomagszűrő szabályok, a queue <queuenév> résszel kiegészítve. Fontos még benne a ’quick’ kulcsszó, hiszen, a pf csomagszűrőről szóló írásban már láthattuk, hogy enélkül itt a csomag nem akadna bele az első sorba, hanem végigmenne a további kettőn, és az utolsó szabály illeszkedne rá, azaz MINDEN csomag az ’other’ nevű queuera illeszkedne.
Az általános szintaktika az ’altq’ –ra (a normál betűsek a változók, a dőlt betűsek pedig ezek értékei):
altq on interface scheduler bandwidth bw qlimit qlim tbrsize size queue { queue_list }
Az általános szintaktika a ’queue’ –ra:
queue name [on interface] bandwidth bw [priority pri] [qlimit qlim] scheduler ( sched_options ) { queue_list }
Hogyan tesztelhetjük, illetve nézhetjük meg, hogy a megfelelő forgalom valóban az általunk kívánt módon „akad-e” bele a szabályokba? Én egy sima http alapú downloaddal teszteltem, kellő méretű filet választva a letöltéshez, hogy meg tudjuk figyelni, valóban leesik-e a letöltés sebessége:
A következőt láttam a lynx felületén:
Kijelenthetjük tehát, hogy sikeres volt ennek az egyébként nagyon szimpla traffic shapernek a beállítása. Tekintsük meg kicsit szemléletesebb módon, hogyan néz ki a queue-tree. Ezt az operációs rendszer ’systat’ parancsával tehetjük meg – többek közt!
# systat queues
Itt jól látható, hogyan épül fel a queue-tree. Ennél is részletesebb, szintén valós idejű statisztikákat a pf saját módszerével is láthatunk:
# pfctl -sq -vv
Itt láthatjuk queue-kat és azok részletes statisztikáit pf módra.
Összegzés
A pf ALTQ frameworkje egy szerintem igazán kiváló és logikus szabályokra épülő traffic shaper. Természetesen, ízlés szerint variálhatjuk a queue-k számát, típusát, a hozzájuk rendelt sávszélességet. Több interface-szel rendelkező rendszerek esetén támogatja a interface-k bridge módban történő kezelését is, lehetővé téve ezzel a transzparens traffic shaper kialakítását is.