🚀 go-pugleaf

WebSpider napisał(a):
> Miałem na FreeBSD 6.1-RELEASE  regułki dla pf'a, miały one rozdzielać DSLa
> na kilka osób, wszystko dziłało kilka miesięcy bez problemu, transfery
> idealnie takie jak założyłem. Teraz całość przeniosłem na OpenBSD 4.3, bez
> zmian i niestety nie działa, łącze jest wysycone do granic.

Pokaż wynik polecenia `pfctl -sa'.

Elb

-- 
- No wiesz, pijany i o trzeciej nad ranem wracasz do domu!?
- A kto powiedział, że wracam? Po gitarę tylko przyszedłem.
===========================================================
FAQ  pl.rec.muzyka.gitara:          http://faq.prmg.art.pl/

Użytkownik "Paweł Kania" napisał :
> Pokaż wynik polecenia `pfctl -sa'.

Wyniki tutaj: http://pliki.k13.pl/konnekt/pfctlsa.txt

Użytkownik "WebSpider" napisał
> Miałem na FreeBSD 6.1-RELEASE  regułki dla pf'a, miały one rozdzielać DSLa
> na kilka osób, wszystko dziłało kilka miesięcy bez problemu, transfery
> idealnie takie jak założyłem. Teraz całość przeniosłem na OpenBSD 4.3, bez
> zmian i niestety nie działa, łącze jest wysycone do granic. Przeglądałem
> konfigurację i nie widzę błędu. Proszę o pomoc w naprowadzeniu co jest nie
> tak.
> Natowanie i binat działa jak trzeba.
> Link do pf.conf'a http://pliki.k13.pl/konnekt/pfconf.txt
> Do karty fxp0 przypisane są IP zewnętrzne z DSLa,
> fxp1 to sieć LAN.

Przycinanie uploadu, tj użytkownika w stronę internetu, działa jak należy.

On 11 Wrz, 08:06, "WebSpider" <webs1...@spamoweee.gmail.com> wrote:
> Użytkownik "WebSpider" napisał
>
> > Miałem na FreeBSD 6.1-RELEASE  regułki dla pf'a, miały one rozdzielać DSLa
> > na kilka osób, wszystko dziłało kilka miesięcy bez problemu, transfery
> > idealnie takie jak założyłem. Teraz całość przeniosłem na OpenBSD 4.3, bez
> > zmian i niestety nie działa, łącze jest wysycone do granic. Przeglądałem
> > konfigurację i nie widzę błędu. Proszę o pomoc w naprowadzeniu co jest nie
> > tak.
> > Natowanie i binat działa jak trzeba.
> > Link do pf.conf'ahttp://pliki.k13.pl/konnekt/pfconf.txt
> > Do karty fxp0 przypisane są IP zewnętrzne z DSLa,
> > fxp1 to sieć LAN.
>
> Przycinanie uploadu, tj użytkownika w stronę internetu, działa jak należy.

Witaj

Najpierw zerknij tutaj: http://www.openbsd.com/faq/pf/pl/queueing.html#altq
A w skrócie, kolejkować możesz tylko ruch wychodzący na interfejsach,
czyli:
pass out na int_wewn to Twoj download
pass out na int_zewn to Twoj upload
Poza tym robisz NAT, więc musisz otagować pakiety, aby po translacji
bsd mógł rozpoznać do którego IP należą.
Masz masę przykładow na necie.

Pozdrawiam, Marcin.

Użytkownik <bsdsiberian@gmail.com> napisał
> Najpierw zerknij tutaj:
> http://www.openbsd.com/faq/pf/pl/queueing.html#altq A w skrócie,
> kolejkować możesz tylko ruch wychodzący na interfejsach, czyli:
> pass out na int_wewn to Twoj download
> pass out na int_zewn to Twoj upload

no i tak jest zrobione, konfigurację zamieściłem wcześniej jaką mam.

> Poza tym robisz NAT, więc musisz otagować pakiety, aby po translacji
> bsd mógł rozpoznać do którego IP należą.

na FBSD nie trzeba tagować by spełniało to moje, dość małe, wymagania.
czy przez to mi nie działa tylko? :>

> Masz masę przykładow na necie.


FAQ o PFie przeczytałem całe, przykłady też oglądałem.
Rozchodzi mi się tylko czemu na Free działa, a na Open'ie nie.

On 11 Wrz, 18:50, "WebSpider" <webs1...@spamoweee.gmail.com> wrote:
> Użytkownik <bsdsiber...@gmail.com> napisał
>
> > Najpierw zerknij tutaj:
> >http://www.openbsd.com/faq/pf/pl/queueing.html#altqA w skrócie,
> > kolejkować możesz tylko ruch wychodzący na interfejsach, czyli:
> > pass out na int_wewn to Twoj download
> > pass out na int_zewn to Twoj upload
>
> no i tak jest zrobione, konfigurację zamieściłem wcześniej jaką mam.
>
> > Poza tym robisz NAT, więc musisz otagować pakiety, aby po translacji
> > bsd mógł rozpoznać do którego IP należą.
>
> na FBSD nie trzeba tagować by spełniało to moje, dość małe, wymagania.
> czy przez to mi nie działa tylko? :>
>
> > Masz masę przykładow na necie.
>
> FAQ o PFie przeczytałem całe, przykłady też oglądałem.
> Rozchodzi mi się tylko czemu na Free działa, a na Open'ie nie.

Czytaj uważnie.
Masz ustawione altq na obydwu interfejsach, natomiast pakiety do
kolejek przypisujesz tylko na jednym interfejsie fxp1.

pass in quick on fxp1 from ip_wewn to any tag user1 queue user1_down
pass out quick on fxp0 from any to any tagged user1 queue user1_up

W ten sposób możesz ograniczyć upload zarówno jak i download.

Pozdrawiam, Marcin

Użytkownik <bsdsiberian@gmail.com> napisał
> Masz ustawione altq na obydwu interfejsach, natomiast pakiety do
> kolejek przypisujesz tylko na jednym interfejsie fxp1.
> pass in quick on fxp1 from ip_wewn to any tag user1 queue user1_down
> pass out quick on fxp0 from any to any tagged user1 queue user1_up
> W ten sposób możesz ograniczyć upload zarówno jak i download.

Przerabiałem takie ustawienia tylko bez tagowania.
Rozumiem o co chodzi, zrobię z tagowaniem i się odezwę.
Dezorientuje mnie tylko fakt, że idealnie taka konfiguracja działała
bez problemu przez półtorej roku.
Dziękuję.

-- 
Pozdrawiam,
Konrad

Dnia Thu, 11 Sep 2008 22:52:50 +0200, WebSpider napisał(a):

> Przerabiałem takie ustawienia tylko bez tagowania.
> Rozumiem o co chodzi, zrobię z tagowaniem i się odezwę.

Nie musi być tagowania, ważne żebyś wiedział co robisz.

> Dezorientuje mnie tylko fakt, że idealnie taka konfiguracja działała
> bez problemu przez półtorej roku.

A nie powinna.

> http://pliki.k13.pl/konnekt/pfconf.txt
> altq on fxp0 hfsc bandwidth 640Kb queue { std_u, a2_u, a3_u, a4_u, a5_u, a6_u, a7_u, k21_u, k22_u, k23_u }
>         queue std_u bandwidth 10Kb hfsc (default)
>         queue a2_u  bandwidth 12Kb hfsc (upperlimit 512Kb) priority 3
>         queue a3_u  bandwidth 12Kb hfsc (upperlimit 200Kb) priority 3
[...]

zamiast priority używaj linkshare (czyli bandwidtch w altq,
pamietaj ze bandwidth jest tutaj stosunkiem pomiedzy dwoma
kojejkami a nie wartością), użyj także realtime - gubisz całą siłę hfsc

> # serwer 
> pass in on  fxp1 proto { icmp, tcp, udp } from 10.1.19.2 to any queue a2_u
> pass out on  fxp1 proto { icmp, tcp, udp } from any to 10.1.19.2 queue a2_d

ruch icmp wyrzuć do jakiejś jednej kolejki, po co to w ogóle ograniczać
 pass quick inet proto icmp from any to any

używaj keep state przecież pf to statefull firewall, rozdziel ruch
tcp od udp i powyższe dwie linijki zamień na coś w stylu:

pass in  quick on fxp1 inet proto udp from 10.1.19.2 to !fxp1 tag a2d    keep state (if-bound) queue a2_d
pass out quick on fxp0 inet proto udp from fxp0      to any   tagged a2d keep state (if-bound) queue a2_u
pass in  quick on fxp1 inet proto tcp from 10.1.19.2 to !fxp1 tag a2d    flags S/SA keep state (if-bound) queue a2_d
pass out quick on fxp0 inet proto tcp from fxp0      to any   tagged a2d flags S/SA keep state (if-bound) queue a2_u

pierwsza linijka pozwala na ruch udp z hosta 10.1.19.2 do serwera,
przypisujemy ją do kolejki a2_d (download), pakiety powrotne wpadną
do niej dzięki użyciu keep state (keep state można używać z ruchem udp),
dodatkowo dzięki !fxp1 nie kolejkujemy pakietów które mają trafić tylko
do serwera (oczywiście jeśli taki ruch przewidujemy to musimy także
dopisać odpowiednie regułki pass)

druga linijka bezpośrednio wrzuca pakiety wyjściowe do kolejek
uploadowych

trzecia i czwarta linijka to to samo tylko dla ruchu tcp - używaj dla
niego 'flags S/SA' - wystarczy analizować pakiet rozpoczynający ruch
reszte załatwi keep state

reszte regułek pozamieniaj analogicznie

-- 
Tomek

Tomasz Sowa napisał(a):
> używaj keep state przecież pf to statefull firewall
[ciach]
> trzecia i czwarta linijka to to samo tylko dla ruchu tcp - używaj dla
> niego 'flags S/SA'

Tomku, ale przecież od wersji 4.1 OpenBSD zarówno keep state jak
i S/SA są ustawiane domyślnie dla wszystkich regułek, także Konrad
na swoim 4.3 w ogóle nie powinien się tym przejmować.

Elb

-- 
- No wiesz, pijany i o trzeciej nad ranem wracasz do domu!?
- A kto powiedział, że wracam? Po gitarę tylko przyszedłem.
===========================================================
FAQ  pl.rec.muzyka.gitara:          http://faq.prmg.art.pl/

> Nie musi być tagowania, ważne żebyś wiedział co robisz.

To w jaki sposób chcesz wyłapać ruch poszczególnych userów z sieci lan
po nacie, by przypiąć ich do odpowiednich kolejek?

> Tomku, ale przecież od wersji 4.1 OpenBSD zarówno keep state jak
> i S/SA są ustawiane domyślnie dla wszystkich regułek, także Konrad
> na swoim 4.3 w ogóle nie powinien się tym przejmować.

Tak zgadza się, ale żeby użyć opcji takich jak np if-bound musisz
zadeklarować w jaki sposób chcesz śledzić stany.

Pozdrawiam, Marcin.

Użytkownik "Tomasz Sowa"  napisał
> zamiast priority używaj linkshare (czyli bandwidtch w altq,
> pamietaj ze bandwidth jest tutaj stosunkiem pomiedzy dwoma
> kojejkami a nie wartością), użyj także realtime - gubisz całą siłę hfsc
heh, przerasta mnie to chyba ;-)
tak czytam różne wątki na grupie, forach i coraz mniej rozumiem.
prosiłbym o naprowadzenie jak ma wyglądać, o czym mam jeszcze doczytać
jeśli chce osiągnać coś takiego:
4Mbit/s, każdy użytkownik ma zagwaranowane minimum 64Kbit/s pasma,
ale maksimum jakie może osiągnąć to 512Kbit/s.

Do tej pory by ograniczyć górną wartość używałem upperlimit,
ale z tego co czytam to większość osób tego nie zaleca bo nie
było tego pierwotnie w hfsc.

Dobrze rozumiem, że dla tej minimalnej wartości trzeba użyć realtime?
Jeśli tak to czym ograniczyć górną wartość?

Dnia Sat, 13 Sep 2008 13:29:28 -0700 (PDT), bsdsiberian@gmail.com
napisał(a):

>> Nie musi być tagowania, ważne żebyś wiedział co robisz.
> 
> To w jaki sposób chcesz wyłapać ruch poszczególnych userów z sieci lan
> po nacie, by przypiąć ich do odpowiednich kolejek?

Pospieszyłem się, rzeczywiście tutaj bez tagowania się nie obejdzie.

-- 
Tomek

Dnia Sun, 14 Sep 2008 10:51:50 +0200, WebSpider napisał(a):

> Do tej pory by ograniczyć górną wartość używałem upperlimit,
> ale z tego co czytam to większość osób tego nie zaleca bo nie
> było tego pierwotnie w hfsc.

w samym hfsc tego nie było, to jest rozszerzenie altq ale nie widze powodu
aby go nie używać
 
> Dobrze rozumiem, że dla tej minimalnej wartości trzeba użyć realtime?

tak

-- 
Tomek

On 15 Wrz, 12:25, Tomasz Sowa <tom...@slimaczek.BEZSPAMOWY.pl> wrote:
> Dnia Sun, 14 Sep 2008 10:51:50 +0200, WebSpider napisał(a):
>
> > Do tej pory by ograniczyć górną wartość używałem upperlimit,
> > ale z tego co czytam to większość osób tego nie zaleca bo nie
> > było tego pierwotnie w hfsc.
>
> w samym hfsc tego nie było, to jest rozszerzenie altq ale nie widze powodu
> aby go nie używać
>
> > Dobrze rozumiem, że dla tej minimalnej wartości trzeba użyć realtime?
>
> tak
>
> --
> Tomek

- realtime'a używaj do ważnych kolejek, które muszą mieć zdefiniowaną
przez Ciebie przepustowość.
- pasmo z góry ograniczaj upperlimitem, u mnie sprawdza się świetnie
- poza tym, skorzystaj z ograniczenia pasma po czasie