5. Dodatek

5.1. NATowe niuanse

Jeśli używamy do NAT-owania programu ipnat to adres źródłowy pakietu wychodzącego z sieci LAN będzie zamieniony zanim trafi do dummynetu, co czasami może uniemożliwić poprawne działanie naszych regułek sterujących ruchem. Można to zachowanie zmienić modyfikując jądro systemu (plik "netinet/ip_output.c") łatką Pawła Małachowskiego dostępną pod adresem "http://unia.3lo.lublin.pl/~pawmal/freebsd/" (UWAGA! Łatka może być nieaktualna, więc stosowanie jej w niewłaściwy sposób może doprowadzić do nieprawidłowego funkcjonowania jądra. Najlepiej zapoznać się z wprowadzanymi przez nią zmianami i dokonać ich samemu na odpowiednim pliku) tak by dla ruchu wychodzącego pakiety były kierowane najpierw przez dummynet, a dopiero później nat-owane.

5.2. Obliczanie rozmiaru bufora (queue) dla rurki lub kolejki

W powyższym tekście pojawia się pojęcie bufora (queue) dla rurki bądź kolejki. Bufor domyślnie (czyli jeśli my go w regułce nie zdefiniujemy) ma wielkość 50 "slotów". Slot to po prostu miejsce na jeden pakiet, czyli domyślnie mamy bufor o wielkości 50 pakietów. Przeważnie taka wielkość (50) jest za duża (50 pakietów po 1500 bajtów to 75-cio kilobajtowy bufor) dla łącza DSL (a takie tu rozważamy). Wielkość bufora można podawać zarówno w slotach (np. queue 10 oznacza bufor na 10 pakietów) albo w kilobajtach tak, jak w przykładach, gdzie jest on odgórnie przeze mnie zdefiniowany. Wielkość bufora można wyliczyać samemu w zależności od tego, jakim łączem dysponujemy i jakie warunki w sieci chcemy uzyskać. Parametr ten można obliczyć dzieląc przepustowość łącza w kilobajtach w danym kierunku ("in" lub "out") na 3 (lub na 4 jeśli chcemy uzyskać większą interaktywność kosztem przepustowości). Dlaczego? Spróbujmy obliczyć wielkość bufora dla pakietów przychodzących ("in") na łączu 512Kbit/s. 512Kbitów/s to 64KBajty/s. Łącze takie może przyjąć 16KB danych w ciągu 250ms, czyli ustawienie bufora na 16KB pozwoli na buforowanie transmisji przez 250ms. Oznacza to, że nasz dummynet będzie generował maksymalne opóźnienie 250ms w jedną stronę, co dla ruchu WWW jest akceptowalne. Jeśli chcemy uzyskać lepsze warunki dla np. gier sieciowych należy kolejce lub rurce przypisać odpowiedni bufor (np. do buforowania transmisji przez maksymalnie 50ms). W związku z tym, że łącze ADSL 128/512Kbit/s jest łączem asynchronicznym opóźnienie transmisji będzie sumą opóźnienia przy ruchu wychodzącym i wchodzącym. Dlatego ustawienie zbyt małej wartości buforów może doprowadzić do znacznego spadku transmisji a ustawienie go na zbyt dużą wartość do zbyt dużych opóźnień (nie akceptowalnych np. przez graczy sieciowych).

6. Na zakończenie

Wiem, że powyższy tekst nie przedstawia wszystkich aspektów omawianego zagadnienia lecz tylko te najważniejsze z punktu widzenia początkującego Administratora lub Użytkownika FreeBSD. Jeśli nie znalazłeś(aś) w tym tekście czegoś lub czujesz niedosyt wiedzy polecam zaznajomić się z dokumentacją systemową (manual) dotyczącą ipfw oraz opracowaniami związanymi z tym zagadnieniem zamieszczonymi w Internecie.
Tekst ten pisany był "z głowy" w oparciu o własne doświadczenie oraz własne skrypty, więc może zawierać błędy i/lub niedociągnięcia. Jeśli takowe znajdziesz bardzo proszę o kontakt - postaram się nanieść poprawki.

Autor: Tomasz "Yautja" Król
yautja(at)bsdguru.org

Komentarze:

Re: Praktyczne IPFW Dodane przez DrOOcik w dniu - 2004-07-10 18:12:01

Piknie, ładnie. Dobre opracowanie. Jestem pełen uznania, lecz w sumie nic nowego.  Uporządkowane pojęcia, zaznaczenie wielu reguł i sztuczek (to tylko 10% mozliwości potężnego i znakomitego narzędzia jakim jest niewątpliwie ipfw - man ipfw :-) , który chyba zresztą na początku w zamierzeniach twórcy miał służyć tylko do analizowania sieci).  Ale... w moim skromnym 2-letnim doświadczeniu w walce z p2p na sieci lokalnej różnie jest z tym dummynetem.  Już chyba kilkadziesiąt razy zmieniałem ustawienia i zawsze coś jest nie tak.  Powyższe regułki i temu podobne w stylu "dynamiczne przydzielanie łącza w zalezności od możliwości i obciążenia" w praktyce na 100% nie zdają egzaminu. Czemu? Sam nie wiem, zawsze jest jakaś furtka dla coraz to wymyślniejszych i "inteligentnych" klientów p2p.  Takie klienty otwierają po kilkadziesiąt (kilkaset) połączeń, zmieniają porty na te "niby" pożądane (80,22 i temu podobne im nie straszne). I co robić?  Co mniej doświadczeni admini rozkładają ręce i... po prostu "z palca" blokują poszczególne porty. Ale ja nie jestem za takim rozwiązaniem. To pójście na łatwiznę. Choć, przyznaję, że czasem nie miałem wyjścia.  W akcie rozpaczy przydzielam poszczególnym userom na sztywno "rurki" i wyłączam poszczególne porty. Ale jak p2p działa na porcie np. 80? W linuxie przetestowałem jakieś tam patche na jądro, które analizują pakiety. Ale przy słabym routerze, pakiety i tak potrafiły zamulić łącze, a i nat działał znacznie wolniej.  Można też wydzielić jakąś "rurkę" lub kilka na p2p na dane porty. Można...   Walka z wiatrakami...  Może macie jakieś ciekawe rozwiązania na przystopowanie "pijawek"?  Bo ja, jak do tej pory nic tylko muszę analizować pakiety, patrzeć na obciążenie i co rusz dopisuję jakąś nową regułkę.  Pozdr.

Re: Praktyczne IPFW Dodane przez promyk w dniu - 2004-08-07 08:26:05

Tak mamy SNORT  Jak chcesz opis instalacji,konfiguracji etc jest na www.bsd.edu.pl  Pozdrawiam

Re: Praktyczne IPFW Dodane przez DrOOcik w dniu - 2004-08-14 19:41:45

Znamy, znamy. "Permanentna inwigilacja" :-) pakietów.  Tylko przy standardowej konfiguracji strasznie zwalnia mi system. "Każde pierdnięcie...", tfu, sorek, każdy wysłany pakiet na we/wy jest analizowany i przy servie typu Pentium II 500 czy coś koło tego - masakra z wydajnością.  Nat zwalnia i to tragicznie. p2p ma przechlapane, ale co z tego, kiedy ogólnie jest niewiele lepiej.  A może źle coś ustawiam? Dam znać, jak coś wyjdzie pożytecznego ze snorta.

Re: Praktyczne IPFW Dodane przez drWarlock w dniu - 2004-08-24 20:28:34

Mozesz sie przesiasc na debiana i zainstalowac HTB

Re: Praktyczne IPFW Dodane przez DrOOcik w dniu - 2004-09-10 20:55:14

Tak, tak, wiem, ale jednak *BSD są znakomite jako routery.  Ostanio stosuje także jako dodatkową broń przed pijawkami ograniczenie na ilość połączeń.  Najlepiej na początku regułek ipfw dodać dla "krnąbnych" userów, co niby mają ograniczone pasmo, wydzielone rurki, a i tak potrafią nieźle obciążyć łącze:  ipfw add nr_regulki tcp from IP_wrednego to any not 80 setup limit src-addr 10  Czyli user na www (80) ma wolną rękę, a inne porty max 10 połączeń. Można ilość portów zwiększyć (not 80,port1,port2, ...) , zmienić limit, ale te 10 powinno im wystarczyć.  Już wysłuchuje te narzekania, że "emule mi jakoś dziwnie chodzi, KaZaa się zacina..." He, he :-)  Pozdr.

ipfw Dodane przez TomBob w dniu - 2006-06-06 23:22:15

Witam,  Artykuł bardzo pouczający aczkolwiek mam 2 pytania...  chodzi mi głównie o opcje wkompilowywane w kernel, tj. autor poleca wkompilowanie     options IPFW2    zaś w artykule 'NATowanie czyli jak zrobić ''maskaradę''' polecane są poniższe opcje:    options IPFIREWALL   options IPFIREWALL_VERBOSE   options IPFIREWALL_VERBOSE_LIMIT=100   options IPFIREWALL_DEFAULT_TO_ACCEPT   options IPDIVERT    Z czego wynika różnica w polecanych opcjach ( używamy ipfw + natd ) ?    Kolejne pytanie wiąże się z Amule.. jest możliwość zdefiniowania aby jakaś aplikacja np. Amule używała konkretnego pipe'a ( bez ręcznego definiowania portów dla pipe'a), czy można to tylko rozwiązać przypisując ręcznie porty wykorzystywane przez tą aplikację do pipe'a ??

Tylko zarejestrowani użytkownicy mogą pisać komentarze.
Prosze zaloguj się i dodaj komentarz.

Powered by AkoComment!