ALTQ Downlink shaping

[Ne0n]

Hallo,

ich weiß, das Thema ist schon einmal durchgekaut worden, aber unter manchen Umständen macht das shapen des Downlinks ja Sinn, siehe hier:
http://lists.freebsd.org/pipermail/freebsd-pf/2005-November/001657.html

Nun bekomme ich es einfach nicht hin. Ausgehend funktioniert es, aber eingehend muss der Regelaufbau logischerweise anders sein. Ich habe es mit folgendem versucht:

...
# fxp0 connected to LAN
# fxp1 connected to WAN

# Queue Definitionen
altq on fxp0 cbq bandwidth 10Mb queue { qidefault, ..., qiFTP }
   ...
   queue qiFTP   bandwidth   1Mb cbq(borrow)

altq on fxp1 cbq bandwidth 10Mb queue { qdefault, ..., qFTP }
   ...
   queue qFTP   bandwidth   1Mb cbq(borrow)

# Ausgehend - funktioniert
pass out log on fxp1 proto {tcp, udp} from any to any port { 21 } queue qFTP

# Eingehend - [edit:] funktioniert
 pass out log on fxp0 proto {tcp, udp} from any port { 21 } to any queue qiFTP

Der Eingehende Traffic fällt laut pftop nicht in die dafür vorgesehene Queue.
[Edit: doch, siehe unten]
Hat jemand eine spontane Idee?

Grüße (nach längerer Abstinenz ),
Ne0n

 

[Ne0n]

Blödsinn. Es klappt mit ftp. Schlechtes Beispiel.
Generell also kein Problem.

Bei SSH (getestet mit scp von größeren Files) allerdings geht es nicht. Klar sind die Packete verschlüsselt, aber muss der PF nicht trotzdem mitbekommen das es vom Port 22 kommt?

Regel dazu:

# Queue Definitionen
altq on fxp0 cbq bandwidth 10Mb queue { qidefault, ..., qiSSH }
   ...
   queue qiSSH   bandwidth   1Mb cbq(borrow)

altq on fxp1 cbq bandwidth 10Mb queue { qdefault, ..., qiSSH }
   ...
   queue qSSH   bandwidth   1Mb cbq(borrow)

# Ausgehend - funktioniert
pass out log on fxp1 proto {tcp, udp} from any to any port { 22 } queue qSSH

# Eingehend - funktioniert nicht
 pass out log on fxp0 proto {tcp, udp} from any port { 22 } to any queue qiSSH

 

[mapet]

das problem bei reinkommendem verkehr ist, dass der verkehr ja schon passiert ist, bevor der kernel ihn verarbeitet. da gab es mal eine diskussion zu auf der openbsd-misc liste. iirc, geht es nicht, eingehenden verkehr zu queuen, da er an der netzwerkkarte aufschlägt, bevor ihn der kernel zu sehen bekommt. bei ausgehendem ist das anders, da der kernel die pakete an die karte weiterreicht.

hth

 

[Ne0n]

Richtig, shaping auf "pass in" funktioniert nicht.

Es handelt sich aber in meiner Config um "pass out" Traffic der internen Netzwerkkarte. Das funktioniert, auch wenn es _meistens_ nicht sinnvoll ist (der Traffic ist ja schon über die Leitung, hat den Flaschenhals schon passiert).
Klappt ja auch für ftp.

Es ist definitiv ein Regel/Verständnisproblem bezüglich des verschlüsselten Datenverkehrs.

Trotzdem Danke - Denkanstoß ist immer gut

 

[morph]

altq on fxp0 cbq bandwidth 10Mb queue { qidefault, ..., qiSSH }
altq on fxp1 cbq bandwidth 10Mb queue { qdefault, ..., qiSSH }

Mit dem richtigen Queue funktioniert das vielleicht auch

 

[Ne0n]

So... es rennt.
Der Name war aber nur ein Tippfehler hier, nicht in der Config. Mit dem falschen Namen hätte pf beim starten bestimmt auch gemotzt.

Der Knackpunkt war ein anderer. "pass out" ist zwar zum shapen die passende Regel, greift aber nicht wenn der Stream aus der anderen richtung initiiert wurde:

Innen nach aussen:
1. interne ip -> anfrage an externe ip - Regel bemerkt den Traffic und greift

Aussen nach innen:
1. interne ip <- anfrage von externer ip
2. interne ip -> antwort an externe ip - Regel greift nicht da Traffic bereits vorher initiiert und erlaubt

Losgeworden bin ich das Problem mit folgender Konstellation:

# Queue Definitionen
altq on fxp0 cbq bandwidth 10Mb queue { qidefault, ..., qiSSH }
   ...
   queue qiSSH   bandwidth   1Mb cbq(borrow)

altq on fxp1 cbq bandwidth 10Mb queue { qdefault, ..., qSSH }
   ...
   queue qSSH   bandwidth   1Mb cbq(borrow)

# Ausgehend
# erste Regel = normal
pass out log on fxp1 proto {tcp, udp} from any to any port { 22 } queue qSSH
# zweite Regel = hat keinen Effekt außer den Rücklaufenden Traffic in die passende Queue zu setzen
pass in log on fxp1 proto {tcp, udp} from any port { 22 } to any queue qSSH

# Eingehend
# erste Regel = normal
pass out log on fxp0 proto {tcp, udp} from any port { 22 } to any queue qiSSH
# zweite Regel = hat keinen Effekt außer den Rücklaufenden Traffic in die passende Queue zu setzen
pass in log on fxp0 proto {tcp, udp} from any to any port {22 } queue qiSSH