ip pokazuje nam połączenia

[ahu@home ahu]$ ip link list
1: lo: <LOOPBACK,UP> mtu 3924 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: dummy: <BROADCAST,NOARP> mtu 1500 qdisc noop 
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1400 qdisc pfifo_fast qlen 100
    link/ether 48:54:e8:2a:47:16 brd ff:ff:ff:ff:ff:ff
4: eth1: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:e0:4c:39:24:78 brd ff:ff:ff:ff:ff:ff
3764: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1492 qdisc pfifo_fast qlen 10
    link/ppp

Twój ekran wynikowy może się trochę różnić, ale powyższy wydruk pochodzi z mojego domowego routera NAT. Wytłumaczę tylko część, jako że nie wszystko jest bezpośrednio związane.

Na początek widzimy interfejs loopback. O ile twój komputer może i powinien pracować bez niego, radziłbym tego nie próbować. Rozmiar MTU (ang. Maximum Transfer Unit - Maksymalnej Jednostki Transmisji) wynosi 3924 oktety i nie spodziewamy się go kolejkować. Ma to sens, ponieważ interfejs ten jest tylko fantazją twojego kernela.

Pominę interfejs dummy, może on nie być obecny na twoim komputerze. Następnie mamy dwa fizyczne interfejsy, jeden po stronie modemu kablowego i drugi podłączony do mojego domowego segmentu ethernetowego. Dalej widzimy interfejs ppp0.

Zauważ brak adresów IP. iproute nie używa koncepcji łączenia 'połączeń' z 'adresami IP'. Po wprowadzeniem aliasów IP, koncepcja 'tego konkretnego' adresu IP stała się jakby mniej ważna.

Pokazano natomiast adresy MAC, identyfikatory sprzętowe naszych interfejsów ethernetowych.

ip pokazuje nam nasze adresy IP

[ahu@home ahu]$ ip address show        
1: lo: <LOOPBACK,UP> mtu 3924 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
2: dummy: <BROADCAST,NOARP> mtu 1500 qdisc noop 
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1400 qdisc pfifo_fast qlen 100
    link/ether 48:54:e8:2a:47:16 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.1/8 brd 10.255.255.255 scope global eth0
4: eth1: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:e0:4c:39:24:78 brd ff:ff:ff:ff:ff:ff
3764: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1492 qdisc pfifo_fast qlen 10
    link/ppp 
    inet 212.64.94.251 peer 212.64.94.1/32 scope global ppp0

Tutaj mamy więcej informacji. Pokazano wszystkie nasze adresy, łącznie ze wskazaniem do których interfejsów należą. 'inet' oznacza Internet (IPv4). Istnieje wiele innych rodzin adresów, ale w tym momencie zupełnie nas nie obchodzą.

Przyjrzyjmy się bliżej eth0. Twierdzi, że związany jest z internetowym adresem '10.0.0.1/8'. Co to oznacza? Człon /8 określa ilość bitów, które należą do Adresu Sieci. Są 32 bity, mamy więc 24 bity na określenie części swojej sieci. Pierwsze 8 bitów z 10.0.0.1 odpowiada 10.0.0.0, naszemu Adresowi Sieciowemu, naszą maską jest więc 255.0.0.0.

Pozostałe bity należą do przestrzeni adresowej tego interfejsu, więc 10.250.3.13 jest bezpośrednio osiągalny przez eth0, tak samo jak na przykład 10.0.0.1.

Z ppp0 jest dokładnie tak samo, mimo że różnią się numerki. Jego adres to 212.64.94.251 bez maski podsieci. Oznacza to, że jest to połączenie punkt-punkt i każdy adres, z wyjątkiem 212.64.94.251 jest zdalny. Jest jednak trochę więcej informacji. Wiemy, że po drugiej stronie połączenia też jest jeden adres - 212.64.94.1. Dodatek /32 oznacza po prostu, że nie ma 'bitów sieci'.

Bardzo ważne żebyś zrozumiał opisywane wyżej zagadnienia. Zajrzyj do wspomnianej wcześniej dokumentacji, jeśli masz problemy.

Możesz również zauważyć 'qdisc', co oznacza Dyscyplinę Kolejkowania (ang. Queueing Discipline). Znaczenie tej funkcji stanie się jasne później.

ip pokazuje nam trasy routingu

Cóż, wiemy jak znaleźć adresy 10.x.y.z i jesteśmy w stanie dotrzeć do 212.64.94.1. To jednak nie wystarcza, musimy mieć jeszcze instrukcje jak dotrzeć do pozostałej części świata. Internet dostępny jest przez nasze połączenie PPP i wygląda na to, że to 212.64.94.1 będzie rozsyłał nasze pakiety po świecie, oraz zbierał i dostarczał odpowiedzi.

[ahu@home ahu]$ ip route show
212.64.94.1 dev ppp0  proto kernel  scope link  src 212.64.94.251 
10.0.0.0/8 dev eth0  proto kernel  scope link  src 10.0.0.1 
127.0.0.0/8 dev lo  scope link 
default via 212.64.94.1 dev ppp0

Wydruk jest samoopisujący się. Pierwsze 4 linie wprost informują o tym, co już zostało wydrukowane po użyciu komendy ip address show, ostatnia linia określa, że reszta adresów będzie osiągalna przez adres 212.64.94.1 - domyślną bramkę. Wiemy, że to bramka po słowie via, które oznacza, że wysyłamy pod ten adres pakiety a on bierze na siebie resztę.

Dla porównania, poniżej wydruk ze standardowej komendy route:

[ahu@home ahu]$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use
Iface
212.64.94.1     0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
10.0.0.0        0.0.0.0         255.0.0.0       U     0      0        0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         212.64.94.1     0.0.0.0         UG    0      0        0 ppp0

Dostęp rozłączny (ang. split access)

Pierwsze to jak routować odpowiedzi na pakiety przychodzące od powiedzmy dostawcy pierwszego, z powrotem tą samą drogą (nie wykorzystując drugiego łącza).

Zdefiniujmy parę nazw symbolicznych. Niech $IF1 oznacza pierwszy interfejs (if1 na rysunku powyżej) a $IF2 drugi interfejs. Następnie niech $IP1 będzie adresem IP interfejsu $IF1 a $IP2 adresem IP skojarzonym z interfejsem $IF2. Następnie, niech $P1 oznacza adres IP pierwszego dostawcy a $P2 drugiego. Na koniec niech $P1_NET będzie siecią IP w której znajduje się $P1, a $P2_NET odpowiednio siecią IP w której jest $P2.

Należy stworzyć dwa dodatkowe wpisy w tabeli routingu, powiedzmy T1 i T2. Dodaje się je do /etc/iproute2/rt_tables. Następnie należy dodać odpowiednio routing w sposób jak poniżej:

         ip route add $P1_NET dev $IF1 src $IP1 table T1
         ip route add default via $P1 table T1
         ip route add $P2_NET dev $IF2 src $IP2 table T2
         ip route add default via $P2 table T2
      

Teraz należy skonfigurować główną tabelę routingu. Dobrym pomysłem jest kierować ruch do bezpośredniego sąsiada przez interfejs, którym ten sąsiad jest podłączony. Zwróć uwagę na argumenty 'src' - zapewniają że wybrany zostanie poprawny wychodzący adres IP.

           ip route add $P1_NET dev $IF1 src $IP1
           ip route add $P2_NET dev $IF2 src $IP2
        

           ip route add default via $P1
        

           ip rule add from $IP1 table T1
           ip rule add from $IP2 table T2
        

ip route add $P0_NET     dev $IF0 table T1
ip route add $P2_NET     dev $IF2 table T1
ip route add 127.0.0.0/8 dev lo   table T1
ip route add $P0_NET     dev $IF0 table T2
ip route add $P1_NET     dev $IF1 table T2
ip route add 127.0.0.0/8 dev lo   table T2                                     

Jest to oczywiście bardzo prosta konfiguracja. Będzie działała prawidłowo dla wszystkich procesów działających na routerze i dla wszystkich połączeń z sieci lokalnej (jeśli włączono translację adresów). Jeśli translacji nie włączono, to albo dostałeś osobne publiczne przestrzenie adresowe od obu dostawców, albo będziesz chciał robić translację adresów dla jednego z dostawców. W obu przypadkach musisz dodać reguły wybierające przez którego dostawcę routować ruch na podstawie adresów IP maszyn w sieci lokalnej (inicjujących ten ruch).

Rozkładanie obciążenia (ang. load balancing)

Drugie pytanie brzmi: jak rozłożyć obciążenie wychodzące na obu dostawców. Odpowiedzią jest: nie jest to specjalnie trudne, jeśli i tak masz już sytuację opisaną w punkcie powyżej.

Zamiast wybierać jednego z dostawców jako trasę domyślną, musisz wskazać obu. Domyślnie jądro będzie rozkładało ruch wychodzący pomiędzy dwie trasy domyślne. Konfiguruje się to w ten sposób:

           ip route add default scope global nexthop via $P1 dev $IF1 weight 1 \
           nexthop via $P2 dev $IF2 weight 1
        

Zwróć jednak uwagę, że równoważenie obciążenia nie będzie doskonałe, a co więcej bazuje na trasach - które przechowywane są w pamięci podręcznej. Innymi słowy, trasy do najczęściej odwiedzanych stron będą prowadziły zawsze przez tego samego dostawcę.

I jeszcze jedno - jeśli naprawdę chcesz coś takiego zastosować, prawdopodobnie powinieneś rzucić okiem na łatki Juliana Anastazowa, znajdujące się pod adresem jego strony, Powinny one ułatwić ci trochę konfigurację takiego podziału ruchu.

Tunelowanie IPv4

Najpierw zajmijmy się tunelowaniem IPv4.

Powiedzmy że masz 3 sieci: Wewnętrzne A i B oraz pośrednią C (lub, powiedzmy Internet).

Mamy więc sieć A:

network 10.0.1.0
netmask 255.255.255.0
router  10.0.1.1

...sieć B:

network 10.0.2.0
netmask 255.255.255.0
router  10.0.2.1

Natomiast jeśli chodzi o sieć C, zakładamy że przekazuje pakiety od A do B i odwrotnie. Jak i dlaczego nas nie interesuje.

Na routerze w sieci A wykonamy:

ip tunnel add netb mode gre remote 172.19.20.21 local 172.16.17.18 ttl 255
ip link set netb up
ip addr add 10.0.1.1 dev netb
ip route add 10.0.2.0/24 dev netb

Omówmy to w paru zdaniach. W linii 1 dodaliśmy urządzenie tunelujące i nazwaliśmy je netb (co jest raczej oczywiste, ponieważ to tam ma prowadzić). Co więcej, określiliśmy, że używamy protokołu GRE (mode gre), zdalny adres to 172.19.20.21 (router po drugiej stronie), nasze tunelowane pakiety powinny pochodzić z 172.16.17.18 (dzięki temu możesz mieć wiele interfejsów w sieci C i określić wprost z którego mają być wysyłane pakiety), oraz, że pole TTL pakietów powinno być ustawiane na 255 (ttl 255).

Druga linia uaktywnia urządzenie.

W trzeciej linii ustaliliśmy adres nowego urządzenia netb na 10.0.1.1. Dla małych sieci jest to w zasadzie w porządku, ale jeśli rozpoczynasz poważne kopanie (WIELE tuneli), powinieneś rozważyć użycie innego zakresu adresów IP dla interfejsów tunelujących (w naszym przykładzie, mógłbyś użyć 10.0.3.0).

W czwartej linii ustawiamy trasę dla sieci B. Zauważ inną notację w masce sieciowej. Jeśli nie jest ci ona znana, oto jak działa: zapisujesz maskę sieciową w formie binarnej i liczysz wszystkie jedynki. Jeśli nie wiesz jak to zrobić, zapamiętaj że 255.0.0.0 to /8, 255.255.0.0 to /16 a 255.255.255.0 to /24. A 255.255.254.0 to /23, gdybyś się zastanawiał.

Ale koniec tego, zacznijmy z routerem w sieci B.

ip tunnel add neta mode gre remote 172.16.17.18 local 172.19.20.21 ttl 255
ip link set neta up
ip addr add 10.0.2.1 dev neta
ip route add 10.0.1.0/24 dev neta

ip link set netb down
ip tunnel del netb

Tunelowanie IPv6

Zajrzyj do sekcji 6, by zapoznać się z krótkim wprowadzeniem do protokołu IPv6 i formacie zapisu adresów.

Do roboty z tunelami.

Zakładamy, że masz następującą sieć IPv6 i chcesz podłączyć się do 6bone lub kolegi.

Network 3ffe:406:5:1:5:a:2:1/96

ip tunnel add sixbone mode sit remote 172.22.23.24 local 172.16.17.18 ttl 255
ip link set sixbone up
ip addr add 3ffe:406:5:1:5:a:2:1/96 dev sixbone
ip route add 3ffe::/15 dev sixbone

Omówmy to. W pierwszej linii stworzyliśmy tunel nazwany sixbone. Nadaliśmy mu tryb pracy sit (co oznacza tunelowanie IPv6 w IPv4) oraz wskazaliśmy gdzie ma być skierowany (remote) i gdzie się zaczynać (local). TTL ustawione jest na maksymalną wartość 255. Następnie, podnieśliśmy interfejs (up). Na koniec dodaliśmy nasz własny adres sieciowy i ustawiliśmy trasę na 3ffe::/15 (co jest obecnie adresem całej 6bone) w tunelu.

Tunele GRE są obecnie preferowanym rodzajem tunelowania. Są standardowe i przyjęte również poza społecznością linuksową, a w związku z tym są Dobrą Rzeczą.

Teoria

Tak jak wyjaśniałem wcześniej, automatyczna zmiana kluczy może wykonać za nas masę pracy. Dokładniej rzecz biorąc, tworzy SA "w locie". Nie powoduje jednak pojawienia się reguł bezpieczeństwa i w zasadzie tak powinno być.

Żeby skorzystać z IKE, skonfiguruj regułę ale nie wskazuj SA. Kernel w momencie odkrycia reguły IPsec bez SA powiadomi demon IKE, który z kolei postara się odpowiednie SA wynegocjować.

Powtórzmy to jeszcze raz: SP opisuje CO chcemy uzyskać, a SA JAK chcemy to zrobić. Zastosowanie demona IKE automatycznie wymieniającego klucze umożliwia nam ograniczenie się tylko do wskazania, CO chcemy uzyskać.

Przykład

Racoon w wersji KAME dostarczany jest z całą masą opcji, z których większość ma bardzo dobre ustawienia domyślne więc nie będziemy ich modyfikować. Tak jak opisałem powyżej, musimy zdefiniować reguły bezpieczeństwa (SP) a nie SA. Pozostawimy ich negocjację demonowi IKE.

W tym przykładzie, 10.0.0.11 i 10.0.0.216 ponownie chcą zestawić kanał komunikacyjny, ale tym razem z pomocą demona racoon. Dla zachowania przejrzystości konfiguracji użyjemy współdzielonych kluczy (ang. "pre-shared keys"). Zastosowanie do uwierzytelnienia partnerów certyfikatów X.509 opisano w osobnym rozdziale, zajrzyj do sekcja Automatyczna wymiana kluczy przy użyciu certyfikatów X.509.

Użyjemy prawie domyślnej konfiguracji, identycznej na obu hostach:

path pre_shared_key "/usr/local/etc/racoon/psk.txt";

remote anonymous
{
        exchange_mode aggressive,main;
        doi ipsec_doi;
        situation identity_only;

       my_identifier address;

       lifetime time 2 min;   # sec,min,hour
       initial_contact on;
       proposal_check obey;       # obey, strict or claim

       proposal {
               encryption_algorithm 3des;
               hash_algorithm sha1;
               authentication_method pre_shared_key;
               dh_group 2 ;
       }
}
 
sainfo anonymous
{
        pfs_group 1;
        lifetime time 2 min;
        encryption_algorithm 3des ;
        authentication_algorithm hmac_sha1;
        compression_algorithm deflate ;
}

Wiele ustawień - myślę że można usunąć więcej by zbliżyć się do domyślnej konfiguracji. Parę rzeczy wartych zwrócenia uwagi - stworzyliśmy dwie sekcje anonimowe pasujące dla wszystkich partnerów zdalnych co ułatwia znakomicie konfigurację. Nie musimy definiować wszystkiego per-host, chyba że bardzo chcemy.

Co więcej, konfiguracja została wykonana w ten sposób, że identyfikowani jesteśmy na podstawie adresu IP ('my_identifier address') i deklarujemy, że jesteśmy w stanie używać algorytmów 3DES, SHA-1 oraz, że będziemy używać współdzielonego klucza zlokalizowanego w pliku psk.txt.

W rzeczonym pliku psk.txt wpisujemy po jednej linicje, która różnić się będzie na obu hostach. Na 10.0.0.11 będzie to:

10.0.0.216       password2

10.0.0.11       password2

Teraz jesteśmy w stanie skonfigurować żądaną SP, która jest bardzo prosta. Na hoście 10.0.0.216:

#!/sbin/setkey -f
flush;
spdflush;

spdadd 10.0.0.216 10.0.0.11 any -P out ipsec
       esp/transport//require;

spdadd 10.0.0.11 10.0.0.216 any -P in ipsec
       esp/transport//require;

#!/sbin/setkey -f
flush;
spdflush;

spdadd 10.0.0.11 10.0.0.216 any -P out ipsec
       esp/transport//require;

spdadd 10.0.0.216 10.0.0.11 any -P in ipsec
       esp/transport//require;

W tym momencie jesteśmy gotowi do uruchomienia racoon! Jeśli już działa, zainicjowanie ruchu z 10.0.0.11 do 10.0.0.216 lub odwrotnie (np. za pomocą telnetu) spowoduje rozpoczęcie przez racoon negocjacji:

12:18:44: INFO: isakmp.c:1689:isakmp_post_acquire(): IPsec-SA
  request for 10.0.0.11 queued due to no phase1 found.
12:18:44: INFO: isakmp.c:794:isakmp_ph1begin_i(): initiate new
  phase 1 negotiation: 10.0.0.216[500]<=>10.0.0.11[500]
12:18:44: INFO: isakmp.c:799:isakmp_ph1begin_i(): begin Aggressive mode.
12:18:44: INFO: vendorid.c:128:check_vendorid(): received Vendor ID: 
  KAME/racoon
12:18:44: NOTIFY: oakley.c:2037:oakley_skeyid(): couldn't find
  the proper pskey, try to get one by the peer's address.
12:18:44: INFO: isakmp.c:2417:log_ph1established(): ISAKMP-SA
  established 10.0.0.216[500]-10.0.0.11[500] spi:044d25dede78a4d1:ff01e5b4804f0680
12:18:45: INFO: isakmp.c:938:isakmp_ph2begin_i(): initiate new phase 2 
  negotiation: 10.0.0.216[0]<=>10.0.0.11[0]
12:18:45: INFO: pfkey.c:1106:pk_recvupdate(): IPsec-SA established: 
  ESP/Transport 10.0.0.11->10.0.0.216 spi=44556347(0x2a7e03b)
12:18:45: INFO: pfkey.c:1318:pk_recvadd(): IPsec-SA established:
  ESP/Transport 10.0.0.216->10.0.0.11 spi=15863890(0xf21052)

Jeśli w tym momencie wykonamy polecenie `setkey -D', które pokazuje nam nasze SA, powinny wyglądać mniej więcej tak:

10.0.0.216 10.0.0.11 
       esp mode=transport spi=224162611(0x0d5c7333) reqid=0(0x00000000)
       E: 3des-cbc  5d421c1b d33b2a9f 4e9055e3 857db9fc 211d9c95 ebaead04
       A: hmac-sha1  c5537d66 f3c5d869 bd736ae2 08d22133 27f7aa99
       seq=0x00000000 replay=4 flags=0x00000000 state=mature 
       created: Nov 11 12:28:45 2002       current: Nov 11 12:29:16 2002
       diff: 31(s)       hard: 600(s)       soft: 480(s)
       last: Nov 11 12:29:12 2002       hard: 0(s)       soft: 0(s)
       current: 304(bytes)       hard: 0(bytes)       soft: 0(bytes)
       allocated: 3       hard: 0       soft: 0
       sadb_seq=1 pid=17112 refcnt=0
10.0.0.11 10.0.0.216 
       esp mode=transport spi=165123736(0x09d79698) reqid=0(0x00000000)
       E: 3des-cbc  d7af8466 acd4f14c 872c5443 ec45a719 d4b3fde1 8d239d6a
       A: hmac-sha1  41ccc388 4568ac49 19e4e024 628e240c 141ffe2f
       seq=0x00000000 replay=4 flags=0x00000000 state=mature 
       created: Nov 11 12:28:45 2002       current: Nov 11 12:29:16 2002
       diff: 31(s)       hard: 600(s)       soft: 480(s)
       last:                            hard: 0(s)       soft: 0(s)
       current: 231(bytes)       hard: 0(bytes)       soft: 0(bytes)
       allocated: 2       hard: 0       soft: 0
       sadb_seq=0 pid=17112 refcnt=0

10.0.0.11[any] 10.0.0.216[any] tcp
       in ipsec
       esp/transport//require
       created:Nov 11 12:28:28 2002 lastused:Nov 11 12:29:12 2002
       lifetime:0(s) validtime:0(s)
       spid=3616 seq=5 pid=17134
       refcnt=3
10.0.0.216[any] 10.0.0.11[any] tcp
       out ipsec
       esp/transport//require
       created:Nov 11 12:28:28 2002 lastused:Nov 11 12:28:44 2002
       lifetime:0(s) validtime:0(s)
       spid=3609 seq=4 pid=17134
       refcnt=3

Automatyczna wymiana kluczy przy użyciu certyfikatów X.509

Wspominałem wcześniej, że zastosowanie współdzielonych kluczy nie jest najwygodniejsze, ponieważ nie są zbyt łatwe do bezpiecznego współdzielenia - a gdy już są współdzielone, przestają być sekretem. Na szczęście w tym momencie technologie wykorzystujące kryptografię asymetryczną wchodzą do gry i rozwiązują problem.

Jeśli każdy z partnerów IPsec stworzy klucz prywatny i publiczny, możemy zestawić bezpieczny kanał komunikacyjny pozwalając obu stronom opublikować swoje klucze publiczne i odpowiednio skonfigurować reguły bezpieczeństwa.

Stworzenie klucza jest relatywnie łatwe, aczkolwiek wymaga trochę pracy. Poniższy opis opiera się o zastosowanie do tego celu narzędzia openssl.

$ openssl req -new -nodes -newkey rsa:1024 -sha1 -keyform PEM -keyout \
  laptop.private -outform PEM -out request.pem

Country Name (2 letter code) [AU]:NL
State or Province Name (full name) [Some-State]:.
Locality Name (eg, city) []:Delft
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Linux Advanced
Routing & Traffic Control
Organizational Unit Name (eg, section) []:laptop
Common Name (eg, YOUR name) []:bert hubert
Email Address []:ahu@ds9a.nl

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

$ openssl x509 -req -in request.pem -signkey laptop.private -out \
  laptop.public
Signature ok
subject=/C=NL/L=Delft/O=Linux Advanced Routing & Traffic \
  Control/OU=laptop/CN=bert hubert/Email=ahu@ds9a.nl
Getting Private key

path certificate "/usr/local/etc/racoon/certs";

remote 10.0.0.216
{
       exchange_mode aggressive,main;
       my_identifier asn1dn;
       peers_identifier asn1dn;

       certificate_type x509 "upstairs.public" "upstairs.private";

       peers_certfile "laptop.public";
       proposal {
              encryption_algorithm 3des;
              hash_algorithm sha1;
              authentication_method rsasig;
              dh_group 2 ;
       }
}

path certificate "/usr/local/etc/racoon/certs";

remote 10.0.0.11
{
       exchange_mode aggressive,main;
       my_identifier asn1dn;
       peers_identifier asn1dn;

       certificate_type x509 "laptop.public" "laptop.private";
 
       peers_certfile "upstairs.public";

       proposal {
              encryption_algorithm 3des;
              hash_algorithm sha1;
              authentication_method rsasig;
              dh_group 2 ;
       }
}

$ openssl dgst upstairs.public 
MD5(upstairs.public)= 78a3bddafb4d681c1ca8ed4d23da4ff1

Windows

FIXME: Napisać to

pfifo_fast

Kolejka ta, dokładnie tak jak wskazuje na to jej nazwa, to tradycyjne `Pierwszy Wszedł, Pierwszy Wyjdzie' (ang. "First In First Out", FIFO). Oznacza to, że żaden pakiet nie będzie specjalnie traktowany (przynajmniej nie wprost). Kolejka ta ma 3 `pasma' (ang. "band"). W każdym z pasm reguły FIFO działają niezależnie. Jednak jeśli w paśmie 0 są jeszcze pakiety, pasmo 1 nie zostanie obsłużone. Tak samo dzieje się w przypadku pasm 1 i 2.

Kernel honoruje tak zwaną flagę `Typu Usługi' (ang. "Type of Service") i zajmuje się ustawianiem opcji `minimalna zwłoka' w pakietach z pasma 0.

Nie pomylcie tej bezklasowej kolejki z klasową kolejką PRIO! Mimo, że zachowują się podobnie, pfifo_fast jest bezklasowa i nie można dodawać innych kolejek do niej przy użyciu polecenia tc.

Token Bucket Filter

Token Bucket Filter (TBF, w wolnym tłumaczeniu "Filtr Wiadra Żetonów") to prosta kolejka z dyscypliną, która przepuszcza tylko dane przychodzące z pewną częstotliwością nie przekraczającą nałożonych ograniczeń, ale z możliwością przyjęcia krótkich serii danych które przekraczają tych ograniczeń.

TBF jest bardzo precyzyjna, przyjazna zarówno dla sieci jak i procesora. Powinna być twoim pierwszym wyborem jeśli chcesz po prostu zwolnić interfejs!

Implementacja TBF składa się z bufora (`wiadra', ang. "bucket"), wypełnianego pewnymi wirtualnymi porcjami danych (`żetonami', ang. "token") z określoną częstotliwością. Najważniejszym parametrem wiadra jest jego rozmiar, określający ilość żetonów które może ono przechować.

Każdy nadchodzący żeton wyjmuje jeden przychodzący pakiet z kolejki danych i jest kasowany z wiadra. Skojarzenie tego algorytmu z dwoma przepływami - żetonów i danych, daje trzy możliwe scenariusze:

• Dane docierają do TBF z częstotliwością równą częstotliwości napływania żetonów. W tym przypadku każdy przychodzący pakiet ma swój żeton i przechodzi przez kolejkę bez zwłoki.

• Dane docierają do TBF z częstotliwością mniejszą niż częstotliwość napływania żetonów. Tylko ich część jest używana, więc te puste zbierane są do momentu osiągnięcia rozmiaru `wiadra'. Mogą być potem użyte do krótkiej serii pakietów przekraczających normalny limit przepustowości.

• Dane docierają do TBF z częstotliwością większą niż częstotliwość napływania żetonów. Oznacza to, że `wiadro' zostanie w końcu opróżnione z pustych żetonów, powodując przez moment zwiększenie przepustowości. Nazywa się to `przekroczeniem limitu' i jeśli pakiety nadal będą napływały z niezmienną częstotliwością, niektóre będą odrzucane.

Ostatni scenariusz jest bardzo ważny, ponieważ umożliwia kształtować przepustowość dostępną dla danych które przechodzą przez filtr.

Akumulacja żetonów zapewnia pewnego rodzaju zapas bezpieczeństwa, który wykorzystany zostanie gdy pakiety zaczną nagle docierać z większą niż dotychczas częstotliwością. W końcu jednak, ciągłe obciążenie większe od maksymalnego zdefiniowanego spowoduje przeładowanie i pakiety zaczną być najpierw opóźniane, a w końcu odrzucane.

Proszę zauważyć, że w implementacji programowej, żetony odpowiadają bajtom a nie pakietom.

# tc qdisc add dev ppp0 root tbf rate 220kbit latency 50ms burst 1540

Sprawiedliwe Kolejkowanie Stochastyczne (ang. "Stochastic Fairness Queueing")

Stochastic Fairness Queueing (SFQ) to prosta implementacja rodziny algorytmów ze sprawiedliwym podziałem pasma. Jest mniej dokładna niż inne, ale wymaga również mniejszej ilości wyliczeń.

Kluczowym pojęciem w SFQ jest konwersacja (lub potok), która odpowiada zwykle sesji TCP lub strumieniowi UDP. Ruch dzielony jest w dużą ilość kolejek FIFO, po jednej na każdą konwersację. Następnie każda z kolejek opróżniana jest na zasadzie `round-robin' tak aby każda z sesji mogła wysłać swoje dane.

Zapewnia to sprawiedliwą pracę i uniemożliwia jednej konwersacji zajęcie całego pasma. SFQ nazywana jest `stochastyczną', ponieważ tak naprawdę nie przydziela kolejki dla każdej sesji, a używa procedury dzielącej ruch na ograniczoną liczbę kolejek przy pomocy algorytmu `mieszającego' (ang. "hashing").

Ponieważ używana jest wartość mieszająca ( wspominany hash ), może dojść do sytuacji w której więcej niż jedna sesja może skończyć w tym samym wiadrze. Oznaczałoby to w praktyce zmniejszenie szansy wysłania pakietu o połowę i podzielenie tym samym na pół dostępnej efektywnej prędkości. By temu zapobiec, SFQ zmienia często algorytm mieszający i nawet jeśli dojdzie do kolizji sesji będzie to działo się tylko przez parę sekund.

Warto zauważyć, że SFQ jest użyteczne w przypadku gdy twój interfejs wychodzący jest naprawdę pełen! Jeśli nie będzie, nie stworzona zostanie kolejka i tak naprawdę nie będzie miało to żadnego efektu. Później omówimy jak połączyć SFQ z innymi dyscyplinami kolejkowania i uzyskać to co najlepsze z obu sytuacji.

W szczególności, zastosowanie SFQ wobec interfejsu ethernetowego podłączonego do modemu kablowego lub rutera DSL jest bezcelowe, bez dalszego nałożenia ograniczeń!

# tc qdisc add dev ppp0 root sfq perturb 10
# tc -s -d qdisc ls
qdisc sfq 800c: dev ppp0 quantum 1514b limit 128p flows 128/1024 perturb 10sec 
 Sent 4812 bytes 62 pkts (dropped 0, overlimits 0)

Przepływ w qdisc z klasami

Ruch docierający do qdisc z klasami, musi zostać rozesłany do klas podrzędnych, czyli `sklasyfikowany'. By określić co zrobić z konkretnym pakietem używa się filtrów. Ważne jest, by zauważyć że to filtry wywoływane są w qdisc a nie odwrotnie!

Filtry dołączone do określonych qdisc odpowiadają decyzją i kolejka używa jej do skolejkowania pakietu w jedną z klas. Każda podklasa może sprawdzić swoje filtry by ewentualnie dopasować się do jeszcze innych założeń czy instrukcji. Jeśli tego nie robi, klasa kolejkuje pakiet do qdisc, ją zawierającą.

Poza zawieraniem w sobie innych kolejek, większość qdisc z klasami wykonuje również kształtowanie. Dzięki temu można zarówno planować pakiety (np. przy użyciu SFQ) i ograniczać częstotliwość z jaką będą wysyłane. Potrzebujesz takiej możliwości gdy masz szybki interfejs (na przykład, ethernet) i wolne urządzenie sieciowe (np. modem kablowy).

Gdybyśmy uruchomili tylko SFQ nic się nie stanie, ponieważ pakiety docierają i opuszczają twój router bez żadnej zwłoki: interfejs wyjściowy jest dużo szybszy niż faktyczna przepustowość łącza. Nie ma więc kolejki, którą możnaby kontrolować.

Rodzina kolejek z klasami: korzenie, uchwyty, rodzeństwo i rodzice

Każdy interfejs ma jedną wychodzącą kolejkę-korzeń, domyślnie jest to wspomniana wcześniej bezklasowa `pfifo_fast'. Każdej z qdisc można przydzielić uchwyt, który będzie potem używany przez polecenia konfigurujące by odwołać się do niej. Poza kolejkami dla ruchu wychodzącego, interfejs może mieć również przypisaną politykę dla ruchu przychodzącego.

Uchwyt kolejki składa się z dwóch części: starszego i młodszego numeru. Charakterystyczną nazwą dla kolejki-korzenia jest `1:', które równe jest `1:0'. Młodszy numer kolejki z dyscypliną zawsze równy jest 0.

Klasy muszą mieć ten sam starszy numer, określający ich rodzica. Musi być on unikalny w danej konfiguracji qdisc dla ruchu wychodzącego lub przychodzącego. Młodszy numer musi być unikalny w obrębie qdisc i jej dzieci.

                     1:   root qdisc
                      |
                     1:1    klasa-dziecko
                   /  |  \
                  /   |   \
                 /    |    \
                 /    |    \
              1:10  1:11  1:12   klasy-dzieci
               |      |     | 
               |     11:    |    klasa-liść
               |            | 
               10:         12:   qdisc
              /   \       /   \
           10:1  10:2   12:1  12:2   klasy-liście

qdisc PRIO

Kolejka PRIO nie zajmuje się tak naprawdę kształtowaniem ruchu, dzieli jedynie ruch na podstawie tego, jak skonfigurowałeś filtry. Możesz traktować ją jak `pfifo_fast' na sterydach - zamiast pasma jest osobna klasa zamiast prostej kolejki FIFO.

Kiedy pakiet zostaje skolejkowany w qdisc PRIO, na podstawie komend filtrujących które podałeś wcześniej, wybierana jest klasa. Domyślnie, stworzone są trzy i zawierają czyste kolejki FIFO bez żadnej struktury wewnętrznej, ale możesz zastąpić je dowolnymi dostępnymi qdisc.

Zawsze gdy pakiet musi zostać wyjęty z kolejki, sprawdza się klasę :1. Wyższe klasy są sprawdzane tylko wtedy, gdy poprzednie nie zwróciły pakietu.

Kolejka PRIO jest bardzo użyteczna, gdy chcesz prioretyzować określone rodzaje ruchu nie tylko na podstawie flag ToS, ale całej potęgi, którą zapewniają filtry tc. Może również zawierać inne kolejki do predefiniowanych 3, podczas gdy `pfifo_fast' jest ograniczona do prostych kolejek FIFO.

Ponieważ kolejka ta nie zajmuje się kształtowaniem ruchu, obowiązuje to samo ostrzeżenie co do SFQ: używaj jej tylko jeśli fizyczne łącze jest naprawdę zapchane, lub wsadź ją do qdisc z klasami, która nie zajmuje się kształtowaniem ruchu. To ostatnie oznacza praktycznie wszystkie modemy kablowe i urządzenia DSL.

Formalnie rzecz biorąc, kolejka PRIO jest planującą kolejką bezstratną.

           1:   root qdisc
          / | \ 
         /  |  \
        /   |   \
      1:1  1:2  1:3    klasy
       |    |    |
      10:  20:  30:    qdiscs    qdiscs
      sfq  tbf  sfq
pasmo  0    1    2

# tc qdisc add dev eth0 root handle 1: prio 
## To *od razu* tworzy klasy 1:1, 1:2, 1:3
  
# tc qdisc add dev eth0 parent 1:1 handle 10: sfq
# tc qdisc add dev eth0 parent 1:2 handle 20: tbf rate 20kbit buffer 1600 limit 3000
# tc qdisc add dev eth0 parent 1:3 handle 30: sfq                               

# tc -s qdisc ls dev eth0 
qdisc sfq 30: quantum 1514b 
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) 

 qdisc tbf 20: rate 20Kbit burst 1599b lat 667.6ms 
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) 

 qdisc sfq 10: quantum 1514b 
 Sent 132 bytes 2 pkts (dropped 0, overlimits 0) 

 qdisc prio 1: bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 174 bytes 3 pkts (dropped 0, overlimits 0)

# scp tc ahu@10.0.0.11:./
ahu@10.0.0.11's password: 
tc                   100% |*****************************|   353 KB    00:00    
# tc -s qdisc ls dev eth0
qdisc sfq 30: quantum 1514b 
 Sent 384228 bytes 274 pkts (dropped 0, overlimits 0) 

 qdisc tbf 20: rate 20Kbit burst 1599b lat 667.6ms 
 Sent 2640 bytes 20 pkts (dropped 0, overlimits 0) 

 qdisc sfq 10: quantum 1514b 
 Sent 2230 bytes 31 pkts (dropped 0, overlimits 0) 

 qdisc prio 1: bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 389140 bytes 326 pkts (dropped 0, overlimits 0)

# tc -s qdisc ls dev eth0
qdisc sfq 30: quantum 1514b 
 Sent 384228 bytes 274 pkts (dropped 0, overlimits 0) 

 qdisc tbf 20: rate 20Kbit burst 1599b lat 667.6ms 
 Sent 2640 bytes 20 pkts (dropped 0, overlimits 0) 

 qdisc sfq 10: quantum 1514b 
 Sent 14926 bytes 193 pkts (dropped 0, overlimits 0) 

 qdisc prio 1: bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 401836 bytes 488 pkts (dropped 0, overlimits 0)

Sławna qdisc CBQ

Tak jak wspomniano wcześniej, kolejka CBQ jest najbardziej skomplikowaną, tą o której jest najwięcej szumu a jednocześnie najmniej ludzi rozumie co robi i jak skonfigurować ją dokładnie tak jak chcemy. Nie dzieje się tak dlatego, że autorzy byli złośliwi lub niekompetentni - przeciwnie, po prostu algorytm CBQ nie jest zbyt precyzyjny i niezbyt pasuje do sposobu w jaki działa Linuks.

Poza byciem kolejką z klasami, CBQ zajmuje się również kształtowaniem ruchu i to właśnie tego nie robi zbyt dobrze. Powinna pracować w ten sposób: jeśli chcesz ograniczyć ruch 10mbit/s do 1mbit/s, łącze powinno być przez 90% bezczynne. Jeśli nie jest, musimy je dławić by BYŁO w 90% czasu faktycznie bezczynne.

Jest to raczej trudne do zmierzenia, więc CBQ pobiera czas bezczynności z ilości mikrosekund pomiędzy wywołaniami sprzętowymi o więcej danych. Po połączeniu tych informacji, CBQ aproksymuje jak bardzo łącze jest zajęte.

Nie jest to raczej ostrożne i nie zawsze prowadzi do poprawnych rezultatów. Na przykład, jaka jest prędkość łącza na interfejsie, który nie potrafi wysłać pełnych 100mbit/s danych - być może z powodu źle zaimplementowanego sterownika? Karty sieciowe PCMCIA również nigdy nie osiągają 100mbit/s ponieważ nie projektowano do tego tej szyny i ponownie - jak skalkulować czas bezczynności?

Robi się jeszcze gorzej, jeśli rozważymy trochę nietypowe urządzenia sieciowe, takie jak PPP ponad Ethernetem czy PPTP ponad TCP/IP. Efektywna przepustowość w tym przypadku to tak naprawdę miara tego jak dobrze działają `rurki' (ang. "pipe") do przestrzeni użytkownika - a działają bardzo wydajnie.

Ludzie, którzy prowadzili pomiary stwierdzili, że CBQ nie zawsze jest bardzo dokładne a czasami w ogóle podaje nieadekwatne rezultaty.

W większości wypadków, działa jednak dobrze. Z dokumentacją, którą masz w ręku, powinieneś poradzić sobie ze skonfigurowaniem jej tak, by działała dobrze.

               1:           root qdisc
               |
              1:1           klasy-dzieci
             /   \
            /     \
          1:3     1:4       klasy-liście
           |       |
          30:     40:       qdiscs
         (sfq)   (sfq)

# tc qdisc add dev eth0 root handle 1:0 cbq bandwidth 100Mbit         \
  avpkt 1000 cell 8
# tc class add dev eth0 parent 1:0 classid 1:1 cbq bandwidth 100Mbit  \
  rate 6Mbit weight 0.6Mbit prio 8 allot 1514 cell 8 maxburst 20      \
  avpkt 1000 bounded

# tc class add dev eth0 parent 1:1 classid 1:3 cbq bandwidth 100Mbit  \
  rate 5Mbit weight 0.5Mbit prio 5 allot 1514 cell 8 maxburst 20      \
  avpkt 1000                       
# tc class add dev eth0 parent 1:1 classid 1:4 cbq bandwidth 100Mbit  \
  rate 3Mbit weight 0.3Mbit prio 5 allot 1514 cell 8 maxburst 20      \
  avpkt 1000

# tc qdisc add dev eth0 parent 1:3 handle 30: sfq
# tc qdisc add dev eth0 parent 1:4 handle 40: sfq

# tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip \
  sport 80 0xffff flowid 1:3
# tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip \
  sport 25 0xffff flowid 1:4

# tc qdisc add dev eth1 root handle 1: cbq bandwidth 10Mbit allot 1514 \
  cell 8 avpkt 1000 mpu 64
 
# tc class add dev eth1 parent 1:0 classid 1:1 cbq bandwidth 10Mbit    \
  rate 10Mbit allot 1514 cell 8 weight 1Mbit prio 8 maxburst 20        \
  avpkt 1000

TC_PRIO..          Numer  Odpowiada w ToS
-------------------------------------------------
BESTEFFORT         0      Maksymalna niezawodność        
FILLER             1      Minimalny koszt              
BULK               2      Maksymalna przepustowość (0x8)  
INTERACTIVE_BULK   4                               
INTERACTIVE        6      Minimalna zwłoka (0x10)      
CONTROL            7                              

# tc class add dev eth1 parent 1:1 classid 1:2 cbq bandwidth 10Mbit     \
  rate 1Mbit allot 1514 cell 8 weight 100Kbit prio 3 maxburst 20        \
  avpkt 1000 split 1:0 defmap c0

# tc class add dev eth1 parent 1:1 classid 1:3 cbq bandwidth 10Mbit     \
  rate 8Mbit allot 1514 cell 8 weight 800Kbit prio 7 maxburst 20        \
  avpkt 1000 split 1:0 defmap 3f

priorytet  wyślij do
0            1:3
1            1:3
2            1:3
3            1:3
4            1:3
5            1:3
6            1:2
7            1:2

# tc class change dev eth1 classid 1:2 cbq defmap 01/01

priorytet  wyślij do
0            1:2
1            1:3
2            1:3
3            1:3
4            1:3
5            1:3
6            1:2
7            1:2

Hierarchiczne Wiadro Żetonów (ang. "Hierarchical Token Bucket")

Martin Devera (<devik>) słusznie zauważył, że CBQ jest skomplikowane i nie wydaje się zoptymalizowane do zastosowania w wielu typowych sytuacjach. Jego hierarchiczne podejście jest bardzo dobrze dostosowane do konfiguracji, w których masz określone pasmo sieciowe do podzielenia wśród różnych zastosowań. Przy okazji wiesz ile każde powinno dostać i mniej więcej ile mogą od siebie pożyczać.

HTB działa tak jak CBQ, ale nie wykonuje przeliczania czasu bezczynności. Zamiast tego, funkcjonuje jako TBF z klasami - stąd jej nazwa. Ma tylko parę parametrów, opisanych dokładniej pod tym adresem.

Rozbudowa konfiguracji HTB doskonale się skaluje przy wzroście skomplikowania. Jeśli chodzi o CBQ, to wiadomo, że jest już skomplikowana na początku! HTB3 (zajrzyj pod ten adres aby sprawdzić informacje o wersjach HTB) jest obecnie częścią oficjalnych źródeł jądra (od 2.4.20-pre1 i 2.5.31). Prawdopodobnie jednak będziesz musiał nadal pobrać załataną wersję tc do obsługi HTB3: wersje oprogramowania w jądrze i w przestrzeni użytkownika muszą być w tej samej wersji lub tc po prostu nie zadziała.

Jeśli akurat masz nowy kernel, lub jesteś w stanie go odpowiednio załatać, powinieneś poważnie rozważyć użycie HTB.

# tc qdisc add dev eth0 root handle 1: htb default 30

# tc class add dev eth0 parent 1: classid 1:1 htb rate 6mbit burst 15k

# tc class add dev eth0 parent 1:1 classid 1:10 htb rate 5mbit burst 15k
# tc class add dev eth0 parent 1:1 classid 1:20 htb rate 3mbit ceil 6mbit burst 15k
# tc class add dev eth0 parent 1:1 classid 1:30 htb rate 1kbit ceil 6mbit burst 15k

# tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10
# tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10
# tc qdisc add dev eth0 parent 1:30 handle 30: sfq perturb 10

# U32="tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32"
# $U32 match ip dport 80 0xffff flowid 1:10
# $U32 match ip sport 25 0xffff flowid 1:20

Trochę prostych przykładów filtrowania

Jak wyjaśniono w rozdziale o Klasyfikatorze, możesz sprawdzić praktycznie wszystko, używając skomplikowanej składni. Na początek, pokażemy jak wskazać podstawowe rzeczy co na szczęście robi się raczej prosto.

Powiedzmy, że mamy kolejkę PRIO nazwaną 10:, zawierającą trzy klasy; chcemy przypisać cały ruch z i do portu 22 do pasma o najwyższym priorytecie

# tc filter add dev eth0 protocol ip parent 10: prio 1 u32 match \ 
  ip dport 22 0xffff flowid 10:1
# tc filter add dev eth0 protocol ip parent 10: prio 1 u32 match \
  ip sport 80 0xffff flowid 10:1
# tc filter add dev eth0 protocol ip parent 10: prio 2 flowid 10:2

Co to znaczy? Dołącz do eth0, węzeł 10: filtr u32 z priorytetem 1, który pasuje dokładnie do portu przeznaczenia 22 i wyślij pakiety pasujące do pasma 10:1. W następnej linijce powtarzamy to dla portu 80. Ostatnia komenda określa, że wszystko to co nie zostało wskazane wprost powinno trafić do pasma 10:2, następnego w kolejności jeśli chodzi o priorytet.

Musisz dodać `eth0', lub jakkolwiek nazywa się twój interfejs, ponieważ każdy ma swoją własną, unikalną przestrzeń uchwytów.

By wybrać adres IP, użyj:

# tc filter add dev eth0 parent 10:0 protocol ip prio 1 u32 \ 
  match ip dst 4.3.2.1/32 flowid 10:1
# tc filter add dev eth0 parent 10:0 protocol ip prio 1 u32 \
  match ip src 1.2.3.4/32 flowid 10:1
# tc filter add dev eth0 protocol ip parent 10: prio 2      \
  flowid 10:2

Polecenia te przydzielają ruch do 4.3.2.1 i z 1.2.3.4 do kolejki z najwyższym priorytetem a resztę ruchu do kolejki z następnym w kolejności priorytetem.

Możesz łączyć warunki - by pasowały do ruchu z 1.2.3.4 z portu 80, wpisz:

# tc filter add dev eth0 parent 10:0 protocol ip prio 1 u32 match ip src 4.3.2.1/32
  match ip sport 80 0xffff flowid 10:1

Wszystkie komendy filtrujące, których będziesz normalnie potrzebował

Większość komend kształtujących ruch zaczyna się od następującego ciągu:

# tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 ..

Po więcej komend filtrujących, zajrzyj do rozdziału o Zaawansowanych Filtrach.

Przykładowa konfiguracja

Pierwszą rzeczą która może przyjść do głowy jest użycie kształtowania ruchu wchodzącego by dać sobie gwarantowane pasmo ;) Konfiguracja odbywa się dokładnie tak jak dowolnego innego interfejsu:

tc qdisc add dev imq0 root handle 1: htb default 20

tc class add dev imq0 parent 1: classid 1:1 htb rate 2mbit burst 15k

tc class add dev imq0 parent 1:1 classid 1:10 htb rate 1mbit
tc class add dev imq0 parent 1:1 classid 1:20 htb rate 1mbit

tc qdisc add dev imq0 parent 1:10 handle 10: pfifo
tc qdisc add dev imq0 parent 1:20 handle 20: sfq

tc filter add dev imq0 parent 10:0 protocol ip prio 1 u32 match \
              ip dst 10.0.0.230/32 flowid 1:10

iptables -t mangle -A PREROUTING -i eth0 -j IMQ --todev 0

ip link set imq0 up

Cel IMQ w iptables jest prawidłowy tylko w łańcuchach PREROUTING i POSTROUTING tabeli przekształceń (ang. "mangle"). Jego składnia wygląda następująco:

IMQ [ --todev n ]       n : numer urządzenia IMQ

Zwróć uwagę na to, że ruch nie jest kolejkowany gdy cel zostaje trafiony, ale dopiero później. Dokładne miejsce, w którym ruch wchodzi do urządzenia IMQ zależy od kierunku ruchu (wejściowy/wyjściowy). Poniżej predefiniowane stałe używane przez iptables:

enum nf_ip_hook_priorities {
        NF_IP_PRI_FIRST = INT_MIN,
        NF_IP_PRI_CONNTRACK = -200,
        NF_IP_PRI_MANGLE = -150,
        NF_IP_PRI_NAT_DST = -100,
        NF_IP_PRI_FILTER = 0,
        NF_IP_PRI_NAT_SRC = 100,
        NF_IP_PRI_LAST = INT_MAX,
};

Dla ruchu przychodzącego, IMQ rejestruje się z priorytetem NF_IP_PRI_MANGLE + 1, co oznacza że pakiety trafiają do niej zaraz po przejściu łańcucha PREROUTING w tablicy przekształceń.

Dla ruchu wychodzącego, IMQ używa NF_IP_PRI_LAST, który bierze pod uwagę fakt, że pakiety odrzucone przez tablice filtrowania nie zajmują dostępnego pasma.

Łaty i trochę informacji znaleźć można pod tym adresem.

Selektor U32

Selektor U32 zawiera definicję wzorca, który zostanie sprawdzony z przetwarzanym pakietem. Dokładniej, definiuje które bity mają pasować z nagłówka pakietu - ale jest to bardzo potężne narzędzie. Spójrzmy na następujący przykład, wzięty wprost z rzeczywistego, całkiem skomplikowanego filtra:

# tc filter add dev eth0 protocol ip parent 1:0 pref 10 u32 \
  match u32 00100000 00ff0000 at 0 flowid 1:10

Na razie zostawmy pierwszą linię w spokoju - wszystkie parametry opisują tablice mieszające filtra. Skupmy się na linii selektora, zawierającej słowo match. Selektor wybiera nagłówki IP, których drugi bajt jest równy 0x10 (0010). Jak łatwo zgadnąć, numer 00ff jest maską testu, mówiącą filtrowi które bajty dokładnie dopasować. Wynosi 0xff, więc bajt ma być równy dokładnie 0x10. Słowo kluczowe at oznacza, że test rozpoczynany jest od określonego przesunięcia (w bajtach) -- w tym przypadku w stosunku do początku pakietu. Tłumacząc to na ludzki język, pakiet będzie pasował do filtra, jeśli pole ToS będzie miało ustawione bity `niska zwłoka'. Zanalizujmy następną regułę:

# tc filter add dev eth0 protocol ip parent 1:0 pref 10 u32 \
  match u32 00000016 0000ffff at nexthdr+0 flowid 1:10

Opcja nexthdr oznacza następny nagłówek zahermetyzowany w pakiecie IP, tzn. nagłówek wyższego protokołu. Test rozpocznie się od początku następnego nagłówka i dotyczyć będzie drugiego, 32-bitowego słowa w nagłówku. W protokołach TCP i UDP pole to zawiera port przeznaczenia. Numer podawany jest w formacie big-endian, tzn. starsze bity pierwsze, więc czytamy to jako 0x16 czyli 22 decymalnie - port usługi SSH jeśli byłoby to TCP. Jak możesz zgadnąć, test jest bez sensu jeśli nie ma kontekstu i omówimy to później.

Jeśli zrozumiałeś wszystko co było wcześniej, łatwo możesz zrozumieć następujący selektor: match c0a80100 ffffff00 at 16. Chodzi o trzy-bajtowy test, począwszy od 17-tego bajtu licząc od startu nagłówka IP. Test pasuje dla pakietów, których docelowym adresem jest sieć 192.168.1.0/24. Po zanalizowaniu przykładów, możemy podsumować to, czego się nauczyliśmy.

Selektory ogólne

Selektory ogóle definiują wzór, maskę i przesunięcie (offset), które stosowane będą w stosunku do zawartości pakietu. Używając ich, można sprawdzić praktycznie dowolny bit w nagłówku IP, lub nagłówku wyższej warstwy. Są jednak trochę trudniejsze do spisania i odczytania, niż selektory specyficzne opisane niżej. Ich ogólna składnia wygląda tak:

match [ u32 | u16 | u8 ] WZÓR MASKA [ at PRZESUNIĘCIE | nexthdr+PRZESUNIĘCIE]

Jedno ze słów kluczowych - u32, u16 lub u8 określa długość wzorca w bitach. Następnie powinny pojawić się `wzór' (ang. "pattern") i `maska', w długości zadeklarowanej wcześniej. Przesunięcie określane jest w bajtach. Jeśli podano dodatkowo nexthdr+, przesunięcie jest relatywne w stosunku do początku nagłówka wyższej warstwy.

Trochę przykładów:

# tc filter add dev ppp14 parent 1:0 prio 10 u32 \
     match u8 64 0xff at 8 \
     flowid 1:4

Pakiet będzie pasował do tej reguły, jeśli jego czas życia (TTL) jest równy 64. TTL to pole zaczynające się za 8-mym bajtem nagłówka IP.

Reguła dotyczy wszystkich pakietów TCP z ustawioną flagą ACK:

# tc filter add dev ppp14 parent 1:0 prio 10 u32 \
     match ip protocol 6 0xff \
     match u8 0x10 0xff at nexthdr+13 \
     flowid 1:3

Użyj tego selektora do wyboru pakietów z ustawioną flagą ACK krótszych niż 64 bajty.

# tc filter add dev ppp14 parent 1:0 protocol ip prio 10 u32 \
            match ip protocol 6 0xff \
            match u8 0x05 0x0f at 0 \
            match u16 0x0000 0xffc0 at 2 \
            match u8 0x10 0xff at 33 \
            flowid 1:3

Ta reguła dotyczy pakietów TCP z ustawioną flagą ACK i nie zawierających żadnych danych. Możemy zobaczyć tu przykład dwóch selektorów. Wynikiem finalnym będzie logiczna operacja AND na rezultatach ich obu. Jeśli przyjrzymy się nagłówkowi IP, widzimy, że bit ACK jest drugim w kolejności, najstarszym bitem (0x10), w 14-tym bajcie nagłówka TCP (at nexthdr+13). Jeśli chodzi o drugi selektor, jeśli chcielibyśmy sobie utrudnić życie, moglibyśmy napisać match u8 0x06 0xff at 9 zamiast używać selektora specyficznego w postaci protocol tcp. 0x06 to numer protokołu TCP a wartość ta zapisana jest w 10-tym bajcie nagłówka IP. Z drugiej strony w tym przykładzie nie możemy użyć żadnego specyficznego selektora dla pierwszego testu, ponieważ nie ma takiego selektora dla bitu ACK nagłówka TCP.

Filtr poniżej to zmodyfikowana wersja wcześniejszego. Różnica polega na tym, że nie sprawdza on długości nagłówka. Dlaczego? Ponieważ powyższy filtr działa tylko na systemach 32-bitowych.

tc filter add dev ppp14 parent 1:0 protocol ip prio 10 u32 \
     match ip protocol 6 0xff \
     match u8 0x10 0xff at nexthdr+13 \
     match u16 0x0000 0xffc0 at 2 \
     flowid 1:3

Selektory specyficzne

Poniższa tabela zawiera listę wszystkich selektorów specyficznych, które autor znalazł w źródłach programu tc. Mogą ułatwić ci życie i zwiększyć czytelność twojej konfiguracji.

FIXME: Tabela znajduje się w osobnym pliku - `selector.html'

FIXME: I nadal tylko po Polsku :-(

FIXME: Trzeba ją zsgmlizować

Trochę przykładów:

# tc filter add dev ppp0 parent 1:0 prio 10 u32 \
     match ip tos 0x10 0xff \
     flowid 1:4

FIXME: test `tcp dport' nie działa tak jak opisano to poniżej:

Powyższa reguła będzie pasować do pakietów z polem ToS ustawionym na wartość 0x10. Zaczyna się ono w drugim bajcie pakiety i ma wielkość jednego bajtu, więc moglibyśmy napisać to za pomocą generalnego selektora: match u8 0x10 0xff at 1. Tkwi tu pewna podpowiedź - selektory specyficzne są zawsze tłumaczone na ogólne i w takiej formie zapisywane w pamięci jądra. Prowadzi to do konkluzji, że selektory tcp i udp są dokładnie takie same i dlatego nie możesz użyć pojedyńczej komendy match tcp dport 53 0xffff by wskazać pakiety TCP wysłane do określonego portu - pasować będą również pakiety UDP wysyłane do tego portu. Musisz pamiętać, żeby podać protokół na koniec poniższej reguły:

# tc filter add dev ppp0 parent 1:0 prio 10 u32 \
        match tcp dport 53 0xffff \
        match ip protocol 0x6 0xff \
        flowid 1:2

Sposoby na określenie polityki

Są w zasadzie dwa. Jeśli skompilowałeś kernel z opcją `szacowania' (ang. "estimators"), może on dokonywać pomiaru dla każdego filtra sprawdzając, ile ruchu przez niego przechodzi. Są bardzo łagodne dla CPU, ponieważ zliczają 25 razy na sekundę ile przepływa danych i kalkulują na tej podstawie częstotliwość przepływu bitów.

Drugi sposób działa przez TBF, co oznacza, że żyje z twoim filtrem. TBF sprawdza tylko ruch DO górnej granicy skonfigurowanego pasma, a jeśli jest ono większe, można kontrolować tylko nadwyżkę.

Akcje do podjęcia przy przekroczeniu pasma

Jeśli twój filtr wykryje taką sytuację, może wykonać jedną z `akcji'. Obecnie, dostępne są trzy:

Przykłady

Jedynym prawdziwym przykładem jest wspomniany dotyczący ochrony hosta przed powodziami SYN.

FIXME: jeśli go używasz, podziel się z nami swoim doświadczeniem

Dlaczego filtry tc dla IPv6 nie działają?

Baza danych zasad routingu (ang. "Routing Policy Database", RPDB) zastąpiła strukturę routingu i adresowania dla IPv4 w jądrze Linuksa, która odpowiadała za całą wspaniałą funkcjonalność opisywaną w tym HOWTO. Niestety, struktura odpowiedzialna za IPv6 została zaimplementowana poza tą bazą. O ile obie współdzielą część mechanizmów, RPDB nie współpracuje z procesem adresowania ani routingu IPv6.

To się na pewno zmieni, musimy tylko trochę cierpliwie poczekać.

FIXME: Czy ktoś nad tym pracuje? Albo przynajmniej ma plany?

Oznaczanie pakietów IPv6 przez ip6tables

ip6tables umożliwia oznaczanie pakietów i przydzielanie im numerów:

# ip6tables -A PREROUTING -i eth0 -t mangle -p tcp -j MARK --mark 1

Nadal jednak nic to nie zmienia - pakiet nie przejdzie przez wspomnianą wcześniej strukturę RPDB.

Zastosowanie selektora u32 do testu pakietu IPv6

Normalnie, IPv6 jest hermetyzowany w tunel SIT i transportowany ponad siecią IPv4. Zajrzyj do sekcji `Tunelowanie IPv6' po więcej informacji jak zestawić taki tunel. Takie podejście do przesyłania pakietów IPv6 umożliwia nam ich filtrowanie na poziomie protokołu IPv4.

Poniższy filtr pasuje do całegu ruchu IPv6 zahermetyzowanego w pakietach IPv4:

# tc filter add dev $DEV parent 10:0 protocol ip prio 10 u32 \
            match ip protocol 41 0xff flowid 42:42

Przyjrzymy się temu. Załóżmy, że pakiet IPv6 został wysłany w IPv4 i oba nie mają ustawionych żadnych opcji. Możemy użyć poniższego filtra by wybrać pakiety ICMPv6 w IPv6 zahermetyzowane w IPv4. Wartość 0x3a (58) to pole typu `next-header' dla ICMPv6.

# tc filter add dev $DEV parent 10:0 protocol ip prio 10 u32 \
           match ip protocol 41 0xff \
           match u8 0x05 0x0f at 0 \
           match u8 0x3a 0xff at 26 \
           flowid 42:42

Dopasowanie adresu przeznaczenia IPv6 wymaga trochę większej ilości pracy. Poniższy filtr pasuje do następującego adresu docelowego: 3ffe:202c:ffff:32:230:4fff:fe08:358d:

# tc filter add dev $DEV parent 10:0 protocol ip prio 10 u32 \
            match ip protocol 41 0xff \
            match u8 0x05 0x0f at 0 \
            match u8 0x3f 0xff at 44 \
            match u8 0xfe 0xff at 45 \
            match u8 0x20 0xff at 46 \
            match u8 0x2c 0xff at 47 \
            match u8 0xff 0xff at 48 \
            match u8 0xff 0xff at 49 \
            match u8 0x00 0xff at 50 \
            match u8 0x32 0xff at 51 \
            match u8 0x02 0xff at 52 \
            match u8 0x30 0xff at 53 \
            match u8 0x4f 0xff at 54 \
            match u8 0xff 0xff at 55 \
            match u8 0xfe 0xff at 56 \
            match u8 0x08 0xff at 57 \
            match u8 0x35 0xff at 58 \
            match u8 0x8d 0xff at 59 \
            flowid 10:13

Tą samą technikę można zastosować do testów podsieci. Na przykład dla 2001::.

# tc filter add dev $DEV parent 10:0 protocol ip prio 10 u32 \
            match ip protocol 41 0xff \
            match u8 0x05 0x0f at 0 \
            match u8 0x20 0xff at 28 \
            match u8 0x01 0xff at 29 \
            flowid 10:13

Podstawowe IPv4

Jako ogólna uwaga warto zaznaczyć, że większość właściwości ograniczania/kształtowania ruchu nie działa na interfejsie loopback, więc testowanie ich na nim nie ma sensu. Limity podaje się w jednostkach zwanych `jiffies' a wymusza się je za pomocą wspomnianego wcześniej TBF'a.

Kernel ma wewnętrzny zegar pracujący w jednostkach 'HZ' (lub `jiffies') na sekundę. Na platformie intelowskiej, `HZ' to prawie 100, więc ustawienie pliku *_rate na powiedzmy 50 spowoduje przesłanie tylko 2 pakietów na sekundę. TBF jest skonfigurowany na przepuszczanie maksymalnie serii po 6 pakietów, jeśli dostępna jest odpowiednia ilość żetonów.

Niektóre wpisy w poniższej liście skopiowano z /usr/src/linux/Documentation/networking/ip-sysctl.txt, autorstwa Aleksieja Kuzniecowa <kuznet@ms2.inr.ac.ru> i Andi Kleen <ak@muc.de>.

Ustawienia dotyczące urządzeń

`DEV' oznacza albo prawdziwy interfejs, lub `all' (wszystkie) lub `default' (domyślny). Ostatnie znaczenie zmienia również ustawienia dla interfejsów, które będą stworzone w przyszłości.

Polityka dotycząca sąsiadów

`DEV' oznacza albo prawdziwy interfejs, lub `all' (wszystkie) lub `default' (domyślny). Ostatnie znaczenie zmienia również ustawienia dla interfejsów, które będą stworzone w przyszłości.

Ustawienia dla routingu

Parametry i użycie

Wprowadzenie

Po pierwsze, dobrze byłoby przeczytać RFC poświęcone temu tematowi (RFC2474, RFC2475, RFC2597 i RFC2598) ze strony IETF DiffServ working Group oraz strony autorstwa Wernera Almesbergera (napisał kod odpowiedzialny za różnicowanie usług w Linuksie).

Z czym jest związany Dsmark?

Dsmark jest kolejką z dyscypliną, która oferuje możliwości potrzebne w `Usługach Zróżnicowanych' (ang. "Differentiated Services") (nazywanych również DiffServ lub po prostu DS). DiffServ jest jedną z dwóch architektur QoS (druga nazywa się Usługami Zintegrowanymi) bazujących na wartościach przenoszonych przez pakiet w polu DS nagłówka IP.

Jednym z pierwszych rozwiązań zaprojektowanych dla IP z myślą o QoS było pole Typ Usługi (bajt ToS) umieszczone w nagłówku IP. Zmieniając tą wartość, możemy wybrać wysoki/niski poziom przepustowości, zwłokę czy też niezawodność. Nie zapewnia to wymaganej elastyczności jeśli chodzi o nowe usługi (takie jak aplikacje czasu rzeczywistego, interaktywne i inne). Po tym pomyśle pojawiły się nowe architektury. Jedną z nich jest DiffServ, która zachowała bity ToS i przemianowane pole DS.

Wskazówki dotyczące Usług Zróżnicowanych

Usługi Zróżnicowane są zorientowane na grupy. Oznacza to, że nie wiemy nic o potokach (którymi zajmą się Usługi Zróżnicowane); wiemy o agragacjach potoków i zastosujemy w stosunku do nich różne zasady, w zależności od tego, do której agregacji należy pakiet.

Kiedy pakiet dociera do węzła brzegowego (węzła wejściowego do domeny DiffServ) można w stosunku do niego zastosować zdefiniowane zasady, poddać go kształtowaniu ruchu i/lub zaznaczyć go (oznaczanie dotyczy przydzielania wartości polu DS. Całkiem jak z krowami :-) ). Jest to znacznik na podstawie którego węzły domeny DiffServ będą decydowały, który poziom QoS zastosować.

Jak pewnie wydedukujesz, Usługi Zróżnicowane zawierają domenę, w której reguły DS będą stosowane. Tak naprawdę możesz o niej myśleć w ten sposób: `Pakiety docierające do mojej domeny będą poddane działaniu reguł, które dyktują zasady klasyfikujące a każdy przemierzany węzeł zastosuje w stosunku do takiego pakietu poziom QoS'.

Tak naprawdę, możesz stosować własne zasady w swoich lokalnych domenach, ale pewne `Ustalenia Poziomu Usług' (ang. "Service Level Agreements") powinny zostać rozważone przy podłączaniu do innych domen DS.

Możesz mieć w tym momencie masę pytań. DiffServ to więcej niż do tej pory powiedziałem. Proszę zrozumieć, że nie potrafię streścić 3 RFC w 50 liniach :-).

Praca z Dsmark

Jak podaje bibliografia DiffServ, rozróżniamy węzły brzegowe i wewnętrzne. Są to dwa ważne punkty w ścieżce obsługiwanego ruchu. Oba typy wykonują klasyfikację gdy otrzymują pakiety. Rezultaty tej klasyfikacji mogą zostać wykorzystane w różnych miejscach procesu DS zanim pakiet zostanie wypuszczony do sieci. Dlatego architektura DiffServ udostępnia strukturę `sk_buff', zawierającą nowe pole nazwane `skb->tc_index', w którym przechowywana jest wartość początkowej klasyfikacji dla późniejszego wykorzystania w trakcie procesu DS.

Wartość `skb->tc_index' zostaje początkowo ustawiona przez qdisc DSMARK, przez pobranie pola DS z nagłówka pakietu IP. Poza tym, klasyfikator `cls_tcindex' przeczyta całość lub część pola `skb->tc_index' i użyje tej wartości by wybrać klasy.

Przyjrzyjmy się najpierw komendzie qdisc DSMARK i jej parametrom:

... dsmark indices INDICES [ default_index DEFAULT_INDEX ] [ set_tc_index ]

• indices: rozmiar tabeli par (maska,wartość). Maksymalna wartość to 2Ćn, gdzie n>=0.

• Default_index: domyślny wskaźnik na wpis w tabeli, jeśli klasyfikator nie dopasuje żadnego warunku.

• Set_tc_index: instruuje proces dsmark by pobrać pole DS i zapisać je do `skb->tc_index'.

Jak działa SCH_DSMARK.

Kolejka wykonuje następujące kroki:

• Jeśli podano opcję `set_tc_index' w komendzie qdisc, pole DS jest zczytywane z pakietu i przechowywane w zmiennej `skb->tc_index'.

• Wywoływany jest klasyfikator. Wynikiem jego działania jest identyfikator klasy, który zapisany zostanie w zmiennej `skb->tc_index' (jeśli nie znajdzie się żaden filtr, który pasuje, używana jest wartość `default_index' - a jeśli jej nie ma, zachowanie może być nieprzewidywalne).

• Po wysłaniu do wewnętrznych qdisc, w których możesz użyć wartości w któregoś z filtrów, identyfikator klasy zwrócony przez wewnętrzne qdisc zostaje zapisany do `skb->tc_index'. Wartość tej zmiennej zostanie użyta w przyszłości, by wskazać indeks w tabeli maska-wartość. Końcowa wartość przypisana pakietowi zostanie uzyskana po wykonaniu następującej operacji:

  Nowe_Pole_DS = ( Stare_Pole_DS & maska ) | wartość
  

  
  
  

• To znaczy, wartość końcowa będzie wynikiem operacji logicznej `i' na starym polu DS i masce, oraz wynikiem operacji logicznej `lub' z parametrem wartości. Spójrz na poniższy diagram by zrozumieć ten proces:

                         skb->ihp->tos
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >
     |                                                       |     ^
     | -- If you declare set_tc_index, we set DS             |     |  <-----May change
     |    value into skb->tc_index variable                  |     |O       DS field
     |                                                      A|     |R
   +-|-+      +------+    +---+-+    Internal   +-+     +---N|-----|----+
   | | |      | tc   |--->|   | |-->  . . .  -->| |     |   D|     |    |
   | | |----->|index |--->|   | |     Qdisc     | |---->|    v     |    |
   | | |      |filter|--->| | | +---------------+ |   ---->(mask,value) |
-->| O |      +------+    +-|-+--------------^----+  /  |  (.  ,  .)    |
   | | |          ^         |                |       |  |  (.  ,  .)    |
   | | +----------|---------|----------------|-------|--+  (.  ,  .)    |
   | | sch_dsmark |         |                |       |                  |
   +-|------------|---------|----------------|-------|------------------+
     |            |         | <- tc_index -> |       |
     |            |(read)   |    may change  |       |  <--------------Index to the
     |            |         |                |       |                    (mask,value)
     v            |         v                v       |                    pairs table
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ->
                         skb->tc_index

Jak wykonać oznaczanie pakietu? Zmień maskę i wartość klasy, którą chciałbyś komentować. Spójrz na następującą linijkę:

tc class change dev eth0 classid 1:1 dsmark mask 0x3 value 0xb8

Teraz wytłumaczymy jak działa filtr TC_INDEX i jak wpasowuje się w to wszystko. Oprócz pracy z usługami DS, TC_INDEX może być używany w innych konfiguracjach.

Filtr TC_INDEX

Poniżej podstawowa komenda deklarująca filtr TC_INDEX:

... tcindex [ hash ROZMIAR ] [ mask MASKA ] [ shift PRZESUNIĘCIE ]
            [ pass_on | fall_through ]
            [ classid CLASSID ] [ police OKREŚLENIE_POLITYKI ]

tc qdisc add dev eth0 handle 1:0 root dsmark indices 64 \
 set_tc_index
tc filter add dev eth0 parent 1:0 protocol ip prio 1 \ 
 tcindex mask 0xfc shift 2
tc qdisc add dev eth0 parent 1:0 handle 2:0 cbq bandwidth 10Mbit \
 cell 8 avpkt 1000 mpu 64
# EF traffic class
tc class add dev eth0 parent 2:0 classid 2:1 cbq bandwidth 10Mbit \
 rate 1500Kbit avpkt 1000 prio 1 bounded isolated allot 1514 weight 1 maxburst 10
# Packet fifo qdisc for EF traffic
tc qdisc add dev eth0 parent 2:1 pfifo limit 5
tc filter add dev eth0 parent 2:0 protocol ip prio 1 \
 handle 0x2e tcindex classid 2:1 pass_on

Po pierwsze, załóżmy że otrzymaliśmy pakiet oznaczony `EF'. Jeśli zapoznasz się z RFC2598 dowiesz się, że rekomendowaną przez DSCP wartością dla ruchu `EF' jest 101110. Oznacza to, że pole DS będzie miało wartość 10111000 (pamiętaj, że mniej znaczące bity w bajcie ToS nie są używane przez DS), lub w zapisie heksdecymalnym 0xB8.

              TC INDEX
              FILTER
   +---+      +-------+    +---+-+    +------+                +-+    +-------+
   |   |      |       |    |   | |    |FILTER|  +-+    +-+    | |    |       |
   |   |----->| MASK  | -> |   | | -> |HANDLE|->| |    | | -> | | -> |       |
   |   |  .   | =0xfc |    |   | |    |0x2E  |  | +----+ |    | |    |       |
   |   |  .   |       |    |   | |    +------+  +--------+    | |    |       |
   |   |  .   |       |    |   | |                            | |    |       |
-->|   |  .   | SHIFT |    |   | |                            | |    |       |-->
   |   |  .   | =2    |    |   | +----------------------------+ |    |       |
   |   |      |       |    |   |       CBQ 2:0                  |    |       |
   |   |      +-------+    +---+--------------------------------+    |       |
   |   |                                                             |       |
   |   +-------------------------------------------------------------+       |
   |                          DSMARK 1:0                                     |
   +-------------------------------------------------------------------------+

A więc dociera pakiet, z polem DS ustawionym na wartość 0xB8. Tak jak wytłumaczyliśmy wcześniej, kolejka DSMARK identyfikowana w tym przykładzie przez wartość 1:0, pobiera wartość z pola DS i zapisuje je w zmiennej `skb->tc_index'. Następny krok w przykładzie będzie dotyczył filtra skojarzonego z tą qdisc (druga linijka w przykładzie). Wykona to następujące operacje:

Wartość1 = skb->tc_index & MASKA
Klucz = Value1 >> PRZESUNIĘCIE

W tym przykładzie, MASKA=0xFC a PRZESUNIĘCIE=2.

Wartość1 = 10111000 & 11111100 = 10111000
Klucz = 10111000 >> 2 = 00101110 -> 0x2E heksdecymalnie

Zwrócona wartość odpowiadać będzie uchwytowi wewnętrznego filtra w qdisc (w tym przykładzie, identyfikatorowi 2:0). Jeśli istnieje filtr z taką wartością id, sprawdzone zostaną odpowiednie instrukcje dotyczące polityki oraz ograniczeń przepustowości/częstotliwości (w tym przypadku filtr je zawiera) i zwrócona zostanie wartość identyfikatora klasy (w naszym przypadku, 2:1), która z kolei zostanie zapisana do zmiennej `skb->tc_index'.

Jednak gdy znaleziony zostanie filtr z danym identyfikatorem, rezultat zależeć będzie od deklaracji flagi `fall_through'. Jeśli jest ona ustawiona, jako identyfikator klasy zwracany jest identyfikator klasy. Jeśli nie, zwracany jest błąd i proces kontynuowany jest na reszcie filtrów. Użycie flagi `fall_through' wymaga jednak ostrożności; powinno odbywać się tylko gdy istnieje prosta relacja między wartościami `skb->tc_index' a identyfikatorem klasy.

Ostatnie parametry, które skomentujemy to wartość mieszająca i `pass_on'. Pierwszy odnosi się do rozmiaru tabeli mieszającej. `pass_on' jest z kolei używany do wskazania, że jeśli nie znaleziony zostanie identyfikator klasy równy zwróconemu wynikowi, należy kontynuować sprawdzanie na następnym filtrze. Domyślną akcją jest `fall_through' (spójrz na następną tabelę).

Spójrzmy na koniec na wartości możliwe do ustawienia w parametrach TC_INDEX:

Nazwa TC                Wartość         Domyślnie
-----------------------------------------------------------------
Hash                    1...0x10000     Zależne od implementacji
Maska                   0...0xffff      0xffff
Przesunięcie            0...15          0
Fall through / Pass_on  Flaga           Fall_through
Identyfikator klasy     Major:minor     żadna
Polityka                .....           żadna

Ten rodzaj filtra jest bardzo potężny i niezbędne jest zapoznanie się z wszystkimi jego możliwościami. Poza tym, nie jest to jedyny filtr, którego można użyć w konfiguracjach DiffServ - można go używać tak jak każdego innego rodzaju filtru.

Polecam zapoznanie się z przykładami DiffServ zawartymi w dystrybucji iproute2. Obiecuję, że uzupełnie ten tekst tak szybko jak będę mógł, poza tym wszystko co wytłumaczyłem jest rezultatem całej masy testów. Chciałbym podziękować wszystkim, którzy wytkną mi ewentualne błędy.

Parametry i użycie

Sama kolejka przychodząca nie wymaga żadnych parametrów. Różni się od innych kolejek qdisc tym, że nie zajmuje korzenia urządzenia. Dołącza się ją w ten sposób:

# tc qdisc add dev eth0 ingress

By zobaczyć na dobry przykład jak można użyć kolejkę dla ruchu przychodzącego, zajrzyj do Książki Kucharskiej.

Diagram przepływu ruchu po implementacji

|----------------------------------------|
|Diagram przepływu ruchu po implementacji|
|----------------------------------------|

INTERNET
/\
||
\/
-----------------donmuang router---------------------
/\                                      /\         ||
||                                      ||         ||
||                                      \/         ||
naret                                  silom       ||
*ruch do portu 80 ===================>(cache)      ||
/\                                      ||         ||
||                                      \/         \/
\\===================================kaosarn, RAS, etc.

Zauważ że sieć jest asymetryczna i mamy dodatkowy `hop' na ścieżce ruchu wychodzącego.

Poniżej opis przepływu pakietu przechodzącego sieć z kaosarn do i z Internetu.

Dla ruchu HTTP:
kaosarn http wywołuje->naret->silom->donmuang->internet
http odpowiada z Internetu->donmuang->silom->kaosarn

Dla wywołań nie będących wywołaniami HTTP (np. telnet):
wychodzące dane z kaosarn->naret->donmuang->internet
przychodzące dane z Internetu->donmuang->kaosarn

Rozwiązanie

Jeśli spotkasz się z tym problemem, możesz wyłączyć Rozpoznawanie MTU trasy ustawiając je ręcznie. Koos van den Hout pisze:

Następujący problem: ustawiam mtu/mru mojego łącza pracującego na PPP na wartość 296, ponieważ to tylko 33k i nie mam wpływu na kolejkowanie po drugiej stronie. Przy 296 odpowiedź na wciśnięcie klawisza jest w sensownych ramach czasowych. A po mojej stronie mam router prowadzący maskaradę na Linuksie. Ostatnio rozdzieliłem `serwer' i `router' tak by większość aplikacji pracowała na innej maszynie niż ta, która prowadzi trasowanie. I pojawił się wielki problem z zalogowaniem na IRC. Wielka panika! Po chwili kopania zorientowałem się, że łącze się z serwerem IRC, dostaję nawet komunikat `połączony' ale nie ma już wiadomości dnia. Sprawdziłem co może być źle i zauważyłem, że już wcześniej miałem problemy z osiągnięciem pewnych witryn WWW w związku z MTU - nie było problemu gdy MTU wynosiło 1500 a pojawił się gdy MTU wynosi 296. Ponieważ serwery IRC blokują prawie każdy rodzaj ruchu nie potrzebny w normalnej pracy, blokują również ICMP. Udało mi się przekonać operatorów serwerów WWW że to była przyczyna problemu, ale administratorzy serwerów IRC nie chcieli tego poprawiać. Musiałem się zatem upewnić, że wychodzący maskaradowany ruch ma mniejsze MTU na łączu zewnętrznym. Z kolei lokalny ruch ethernetowy ma mieć normalne MTU (dla czegoś takiego jak np. ruch NFS).

Rozwiązanie:

ip route add default via 10.0.0.1 mtu 296

(10.0.0.1 to domyślna brama i wewnętrzny adres routera prowadzącego maskaradę)

Generalnie, możliwe jest wymuszenie rozpoznawania trasy przez MTU poprzez określenie specyficznych tras. Na przykład, jeśli tylko określona podsieć powoduje problemy, to powinno pomóc:

ip route add 195.96.96.0/24 via 10.0.0.1 mtu 1000

Dlaczego nie działa to najlepiej w domyślnej konfiguracji

Dostawcy Internetowi doskonale zdają sobię sprawę, że często sprawdza się jak szybko można przez nich ściągać dane. Poza dostępną szerokością pasma, prędkość ściągania cierpi również od gubionych pakietów co mocno odbija się na wydajności TCP/IP. Oczywiście duże kolejki mogą temu zapobiec i zwiększyć szybkość ściągania. I w związku z tym, zwykle dostawcy Internetowi tak konfigurują swoje urządzenia.

Odbija się to jednak na usługach interaktywnych. Informacja o przyciśnięciu klawisza musi przejść kolejkę wysyłającą co może zająć nawet całe sekundy (!) i trafić do zdalnej maszyny. Znak odpowiadający kodowi klawisza jest następnie wyświetlany, co powoduje powrót pakietu przez kolejkę odbierającą zlokalizowaną u dostawcy i dopiero dociera on do twojego komputera.

Ten dokument wyjaśnia jak manipulować procesem kolejkowania na wiele sposobów, ale niestety nie możemy tego robić na wszystkich kolejkach. Oczywiście kolejki w urządzeniach dostawców są poza naszym zasięgiem, ale kolejka wysyłająca prawdopodobnie znajduje się w naszym modemie kablowym lub DSL. Możesz mieć lub możesz nie mieć do niej dostępu. Zwykle nie masz.

I co zrobić? Ponieważ nie możemy kontrolować żadnej z tych kolejek, muszą zostać wyeliminowane i przeniesione na router linuksowy. To na szczęście jest możliwe.

Gdy już to zostało zrobione, wyeliminowaliśmy zupełnie kolejkę przychodzącą (poza krótkimi seriami) i uzyskaliśmy możliwość zarządzania kolejką wychodzącą z całą potęgą którą oferuje Linux.

To co pozostaje, to upewnić się, że ruch interaktywny obsługiwany jest przed kolejką wychodzącą. Aby zapewnić sytuację, w której jednoczesne wrzucanie i ściąganie danych nie szkodzi sobie, przesuwamy również na czoło tej kolejki pakiety ACK. To właśnie to powoduje zwykle poważne spowolnienia obserwowane gdy generowane jest dużo ruchu w obie strony. `Potwierdzenia' (ang. "acknowledgements", ACK) dla ruchu przychodzącego muszą konkurować z ruchem wychodzącym i w związku z tym ich dotarcie jest opóźnianie.

Jeśli zrobimy to wszystko, dostaniemy następujące pomiary na doskonałym łączu ADSL z xs4all w Holandii:

Podstawowe opóźnienia:
round-trip min/avg/max = 14.4/17.1/21.7 ms

Bez `udrożniacza' ruchu podczas pobierania danych:
round-trip min/avg/max = 560.9/573.6/586.4 ms

Bez `udrożniacza' ruchu podczas wysyłania danych:
round-trip min/avg/max = 2041.4/2332.1/2427.6 ms

Z `udrożniaczem', podczas wysyłania danych z prędkością 220kbit/s:
round-trip min/avg/max = 15.7/51.8/79.9 ms

Z `udrożniaczem', podczas pobierania danych z prędkością 850kbit/s:
round-trip min/avg/max = 20.4/46.9/74.0 ms

Wysyłanie i pobieranie danych jednocześnie na prawie maksymalnej prędkości.
Opóźnienia skaczą do 850ms, choć nadal nie wiem dlaczego.

To czego możesz spodziewać się po tym skrypcie bardzo zależy od faktycznej prędkości wysyłania danych. Podczas wysyłania danych z pełną prędkością, zawsze będzie pakiet poprzedzający twój wciśnięty klawisz. Jest to minimalna wartość opóźnienia, którą możesz osiągnąć - podziel MTU prez prędkość wysyłania danych. Wartości typowe będą oscylowały trochę powyżej tej wartości. Zmniejszenie MTU powinno przynieść poprawę wyników!

Poniżej dwie wersje tego skryptu, jeden z doskonałym HTB Devik'a a drugi z CBQ dostępną w każdym jądrze Linuksa, w przeciwieństwie do HTB. Oba są przetestowane i pracują dobrze.

Skrypt (CBQ)

Działa na wszystkich kernelach. W obrębie kolejki CBQ umieszczamy dwie `Kolejki ze Stochastycznym Równym Podziałem' (SFQ) by upewnić się, że wiele strumieni przenoszących dane `masowe' nie będą sobie przeszkadzać.

Ruch przychodzący podlega polityce wykonywanej przez filtr tc zawierających TBF.

Możesz ulepszyć ten skrypt przez dodanie słowa kluczowego `bounded' do linii zaczynającej się od `tc class add .. classid 1:20'. Jeśli zmniejszysz wartość swojego MTU, pamiętaj o obniżeniu wartości `allot' i `avpkt'!.

#!/bin/bash 

# Konfiguracja dla połączenia internetowego w domu
# 
#
# Ustaw poniższe wartości trochę poniżej faktycznych prędkości
# ściągania i wysyłania (w kilobitach)
DOWNLINK=800
UPLINK=220
DEV=ppp0

# wyczyść kolejki dla wysyłania i ściągania danych, nie informuj o błędach
tc qdisc del dev $DEV root    2> /dev/null > /dev/null
tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null

###### wysyłanie danych

# instalujemy w korzeniu CBQ

tc qdisc add dev $DEV root handle 1: cbq avpkt 1000 bandwidth 10mbit 

# kształtujemy wszystko do prędkości $UPLINK - zapobiega to tworzeniu
# się dużych kolejek na modemie DSL co zniszczyłoby panowanie nad
# opóźnieniami

tc class add dev $DEV parent 1: classid 1:1 cbq rate ${UPLINK}kbit \
allot 1500 prio 5 bounded isolated 

# klasa z dużym priorytetem 1:10:

tc class add dev $DEV parent 1:1 classid 1:10 cbq rate ${UPLINK}kbit \
   allot 1600 prio 1 avpkt 1000

# klasa domyślna dla ruchu `masowego' 1:20 - otrzymuje trochę mniej
# ruchu i ma mniejszy priorytet

tc class add dev $DEV parent 1:1 classid 1:20 cbq rate $[9*$UPLINK/10]kbit \
   allot 1600 prio 2 avpkt 1000

# obie klasy kontrolowane są przez SFQ:
tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10

# włączamy filtry
# TOS Minimum Delay (ssh, NOT scp) in 1:10:
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
      match ip tos 0x10 0xff  flowid 1:10

# ICMP (protokół IP numer 1) w klasie interaktywnej 1:10 tak, byśmy
# mogli wykonywać pomiary i pochwalić się naszym przyjaciołom
tc filter add dev $DEV parent 1:0 protocol ip prio 11 u32 \
       match ip protocol 1 0xff flowid 1:10

# By zwiększyć prędkość ściągania danych w trakcie wysyłania, pakiety
# ACK umieszczamy do klasy interaktywnej

tc filter add dev $DEV parent 1: protocol ip prio 12 u32 \
   match ip protocol 6 0xff \
   match u8 0x05 0x0f at 0 \
   match u16 0x0000 0xffc0 at 2 \
   match u8 0x10 0xff at 33 \
   flowid 1:10

# cała `nie-interaktywna' reszta trafia do 1:20

tc filter add dev $DEV parent 1: protocol ip prio 13 u32 \
   match ip dst 0.0.0.0/0 flowid 1:20

########## ściąganie #############
# spowolnij ściąganie do wartości trochę mniejszej niż prawdziwa prędkość
# połączenia by zapobiec kolejkowaniu u dostawcy internetowego.
# Poeksperymentuj by dopasować się do maksymalnej wartości która jest
# akceptowalna. Dostawcy mają zwykle potężne kolejki by upewnić się, że
# duże transfery odbywają się szybko
#
# dołączamy określanie polityki dla ruchu przychodzącego

tc qdisc add dev $DEV handle ffff: ingress

# filtrujemy do niego wszystko (0.0.0.0/0) i odrzucamy wszystko co
# przychodzi zbyt szybko:

tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
   0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1

Jeśli ostatnie dwie linijki powodują błąd, uaktualnij swoje narzędzie tc do nowszej wersji!

Skrypt (HTB)

Poniższy skrypt osiąga cele przy użyciu wspaniałej kolejki HTB, o której możesz poczytać więcej wyżej. Warto pomęczyć się z łataniem kernela!

#!/bin/bash

# Konfiguracja dla połączenia internetowego w domu
# 
#
# Ustaw poniższe wartości trochę poniżej faktycznych prędkości
# ściągania i wysyłania (w kilobitach)
DOWNLINK=800
UPLINK=220
DEV=ppp0

# wyczyść kolejki dla wysyłania i ściągania danych, nie informuj o błędach
tc qdisc del dev $DEV root    2> /dev/null > /dev/null
tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null

###### wysyłanie danych

# zainstaluj w korzeniu kolejkę HTB, skieruj domyślnie ruch do 1:20:

tc qdisc add dev $DEV root handle 1: htb default 20

# kształtujemy wszystko na prędkości $UPLINK - zapobiega to tworzeniu
# się dużych kolejek na modemie DSL co zniszczyłoby panowanie nad
# opóźnieniami

tc class add dev $DEV parent 1: classid 1:1 htb rate ${UPLINK}kbit burst 6k

# klasa z dużym priorytetem 1:10:

tc class add dev $DEV parent 1:1 classid 1:10 htb rate ${UPLINK}kbit \
   burst 6k prio 1

# klasa domyślna dla ruchu `masowego' 1:20 - otrzymuje trochę mniej
# ruchu i ma mniejszy priorytet

tc class add dev $DEV parent 1:1 classid 1:20 htb rate $[9*$UPLINK/10]kbit \
   burst 6k prio 2

# obie klasy kontrolowane są przez SFQ:
tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10

# Minimalna zwłoka w polu ToS (ssh, NIE scp) dla 1:10:
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
      match ip tos 0x10 0xff  flowid 1:10

# ICMP (protokół IP numer 1) w klasie interaktywnej 1:10 tak byśmy
# mogli wykonywać pomiary i pochwalić się naszym przyjaciołom
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
       match ip protocol 1 0xff flowid 1:10

# By zwiększyć prędkość ściągania danych w trakcie wysyłania, pakiety
# ACK wsadzamy do klasy interaktywnej

tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \
   match ip protocol 6 0xff \
   match u8 0x05 0x0f at 0 \
   match u16 0x0000 0xffc0 at 2 \
   match u8 0x10 0xff at 33 \
   flowid 1:10

# cała `nie-interaktywna' reszta trafia do 1:20


########## ściąganie #############
# spowolnij ściąganie do wartości trochę mniejszej niż prawdziwa prędkość
# połączenia by zapobiec kolejkowaniu u dostawcy internetowego. Poeksperymentuj
# by dopasować się do maksymalnej wartości która jest akceptowalna.
# Dostawcy mają zwykle potężne kolejki by upewnić się, że duże transfery
# odbywają się szybko
#
# dołączamy określanie polityki dla ruchu przychodzącego

tc qdisc add dev $DEV handle ffff: ingress

# filtrujemy do niego wszystko (0.0.0.0/0) i odrzucamy wszystko co
# przychodzi zbyt szybko:

tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
   0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1

Jeśli chcesz by ten skrypt uruchamiany był po połączeniu ppp, skopiuj go do /etc/ppp/ip-up.d.

Jeśli ostatnie dwie linijki powodują błąd, uaktualnij swoje narzędzie tc do nowszej wersji!

Zoptymalizujmy cenne pasmo

Na początek stworzymy trochę qdisc do których klasyfikować będziemy ruch. Tworzymy qdisc HTB z 6 klasami z malejącymi priorytetami. Mamy klasy które zawsze będą przynajmniej wypełniały dostępne pasmo, ale mogą używać pasmo innych klas jeśli one go nie wykorzystują. Przypominam, że klasy z wyższym priorytetem (z niższym numerem priorytetu) dostają pierwsze dodatkowe pasmo. Fizycznie połączenie stanowi linia ADSL 2Mbit/s downstream na 300kbit/s upstream. Używam prędkości 240kbit/s jako górnej wartości ponieważ wyższe ustawienie powoduje wzrost opóźnień w związku z buforowaniem pomiędzy nami a zdalnymi hostami. Parametr ten należy oczywiście dobrać eksperymentalnie, podnosząc go i opuszczając obserwując uważnie wartości opóźnień.

Zmień wartość CEIL na 75% twojej przepustowości upstream na początek i tam gdzie ja używam eth0 ty wstaw swój interfejs publiczny. Na początek zaczniemy wpisując w powłoce roota:

CEIL=240
tc qdisc add dev eth0 root handle 1: htb default 15
tc class add dev eth0 parent 1: classid 1:1 htb rate ${CEIL}kbit \
 ceil ${CEIL}kbit
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 80kbit \
 ceil 80kbit prio 0
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 80kbit \
 ceil ${CEIL}kbit prio 1
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 20kbit \
 ceil ${CEIL}kbit prio 2
tc class add dev eth0 parent 1:1 classid 1:13 htb rate 20kbit \
 ceil ${CEIL}kbit prio 2
tc class add dev eth0 parent 1:1 classid 1:14 htb rate 10kbit \
 ceil ${CEIL}kbit prio 3
tc class add dev eth0 parent 1:1 classid 1:15 htb rate 30kbit \
 ceil ${CEIL}kbit prio 3
tc qdisc add dev eth0 parent 1:12 handle 120: sfq perturb 10
tc qdisc add dev eth0 parent 1:13 handle 130: sfq perturb 10
tc qdisc add dev eth0 parent 1:14 handle 140: sfq perturb 10
tc qdisc add dev eth0 parent 1:15 handle 150: sfq perturb 10

     +---------+
     | root 1: |
     +---------+
          |
     +---------------------------------------+
     | klasa 1:1                             |
     +---------------------------------------+
        |      |      |      |      |      |      
     +----+ +----+ +----+ +----+ +----+ +----+
     |1:10| |1:11| |1:12| |1:13| |1:14| |1:15| 
     +----+ +----+ +----+ +----+ +----+ +----+

Klasyfikacja pakietów

Stworzyliśmy już konfigurację samych qdisc, ale nie wykonujemy jeszcze żadnej klasyfikacji - wszystkie pakiety trafiają w tym momencie do klasy 1:15 (ponieważ użyliśmy tc qdisc add dev eth0 root handle 1: htb default 15). Musimy teraz określić, które pakiety mają trafić do której klasy. W zasadzie to najważniejsza część konfiguracji.

Skonfigurujemy teraz filtry, za pomocą których iptables sklasyfikują nam ruch. Naprawdę wolę to robić za pomocą iptables, ponieważ są bardzo elastyczne i dodatkowo udostępniają ilość trafień dla każdej reguły. Co więcej, cel RETURN powoduje, że nie trzeba przeglądać wszystkich reguł. Wykonujemy co następuje:

tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle 1 fw classid 1:10
tc filter add dev eth0 parent 1:0 protocol ip prio 2 handle 2 fw classid 1:11
tc filter add dev eth0 parent 1:0 protocol ip prio 3 handle 3 fw classid 1:12
tc filter add dev eth0 parent 1:0 protocol ip prio 4 handle 4 fw classid 1:13
tc filter add dev eth0 parent 1:0 protocol ip prio 5 handle 5 fw classid 1:14
tc filter add dev eth0 parent 1:0 protocol ip prio 6 handle 6 fw classid 1:15

Na początek, powinieneś zrozumieć jak pakiety podróżują przez filtry w iptables:

Pakiet   +------------+           +---------+           +-------------+
wchodzi -| PREROUTING |--decyzja--| FORWARD |--------+--| POSTROUTING |- Pakiet
         +------------+  routingu +-­-------+        |  +-------------+ wychodzi
                           |                         |
                       +-------+                 +--------+   
                       | INPUT |-Procesy lokalne-| OUTPUT |
                       +-------+                 +--------+

Następnie każemy jądru faktycznie wykonywać NAT, tak by klienci z sieci prywatnej mogli nawiązywać połączenia na zewnątrz:

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s 172.17.0.0/255.255.0.0 -o eth0 -j SNAT \
  --to-source 212.170.21.172

tc -s class show dev eth0

Zaczniemy teraz znaczyć pakiety dodając reguły do łańcucha PREROUTING w tablicy przekształceń:

iptables -t mangle -A PREROUTING -p icmp -j MARK --set-mark 0x1
iptables -t mangle -A PREROUTING -p icmp -j RETURN

tc -s class show dev eth0

iptables -t mangle -A PREROUTING -m tos --tos Minimize-Delay \
  -j MARK --set-mark 0x1
iptables -t mangle -A PREROUTING -m tos --tos Minimize-Delay \
  -j RETURN
iptables -t mangle -A PREROUTING -m tos --tos Minimize-Cost \
  -j MARK --set-mark 0x5
iptables -t mangle -A PREROUTING -m tos --tos Minimize-Cost \
  -j RETURN
iptables -t mangle -A PREROUTING -m tos --tos Maximize-Throughput \
  -j MARK --set-mark 0x6
iptables -t mangle -A PREROUTING -m tos --tos Maximize-Throughput \
  -j RETURN

iptables -t mangle -A PREROUTING -p tcp -m tcp --sport 22 \
  -j MARK --set-mark 0x1
iptables -t mangle -A PREROUTING -p tcp -m tcp --sport 22 \
  -j RETURN

iptables -t mangle -I PREROUTING -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN \
  -j MARK --set-mark 0x1
iptables -t mangle -I PREROUTING -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN \
  -j RETURN

iptables -t mangle -A PREROUTING -j MARK --set-mark 0x6

Kolejnym dobrym pomysłem będzie wykonanie tego samego dla reguł w łańcuchu OUTPUT, powtórz więc wszystkie polecenia podając -A OUTPUT zamiast PREROUTING ( s/PREROUTING/OUTPUT/ ). Dzięki temu ruch generowany lokalnie a nie tylko routowany zostanie również sklasyfikowany. Osobiście kończę łańcuch OUTPUT regułą -j MARK --set-mark 0x3 tak, by cała reszta ruchu generowanego lokalnie miała większy priorytet.

Ulepszanie naszej konfiguracji

Powinniśmy mieć teraz działającą konfigurację. Spędź trochę czasu analizując wykresy i sprawdzając jak dokładnie wykorzystywana jest dostępna przepustowość. Sam spędziłem nad tym wiele godzin i doprowadziłem swoje połączenie do idealnego stanu - jeśli coś ustawisz źle, zaczną pojawiać się błędy wygasania połączeń lub nowo tworzone połączenia TCP nie będa mogły dojść do skutku.

Jeśli ustalisz, że niektóre klasy cały czas są pełne dobrze jest spróbować dołączyć dodatkową qdisc tak by podział pasma był bardziej sprawiedliwy. Na przykład w ten sposób:

tc qdisc add dev eth0 parent 1:13 handle 130: sfq perturb 10
tc qdisc add dev eth0 parent 1:14 handle 140: sfq perturb 10
tc qdisc add dev eth0 parent 1:15 handle 150: sfq perturb 10

Niech to wszystko dzieje się samo przy starcie

Możemy to osiągnąć na wiele sposobów. Napisałem skrypt w powłoce, /etc/init.d/packetfilter, który akceptuje składnię [start | stop | stop-tables | start-tables | reload-tables]. Konfiguruje on wszystkie qdisc i ładuje potrzebne moduły jądra - zachowując się jak demon. Ten sam skrypt ładuje reguły dla iptables z osobnego pliku /etc/network/iptables-rules. Trochę go ulepszę i udostępnie pod tym adresem

ARP & Proxy-ARP

Kiedy komputer chce rozmawiać z innym w tym samym segmencie sieci fizycznej, wysyła pakiet ARP brzmiący w uproszczonej wersji tak: `kto ma 10.0.0.1 niech powie 10.0.0.7'. W odpowiedzi na taki pakiet, 10.0.0.1 odpowiada krótkim `ja mam'.

10.0.0.7 wysyła pakiet z adresem sprzętowym wymienionym w pakiecie `ja mam'. Zapisuje również ten adres na relatywnie długi czas a gdy on upłynie, ponownie rozsyła takie zapytanie.

Podczas budowy pseudo-mostu, instruujemy most by odpowiadał na takie pakiety ARP odsyłając swój adres, co spowoduje, że komputery będą wysyłały swoje pakiety przez niego. Most przetwarza otrzymane w ten sposób pakiety i rozsyła je do odpowiednich interfejsów.

Krótko mówiąc, kiedykolwiek komputer po jednej stronie mostu zapyta o adres sprzętowy komputera po drugiej stronie, most odpowiada pakietem `przekaż go mnie'.

W ten sposób, cały ruch przesyłany jest do prawidłowej lokalizacji i przechodzi przez most.

Skonfigurujmy to!

W zamierzchłych czasach można było rozkazać kernelowi Linuksa by prowadził `proxy-ARP' dla każdej podsieci. By skonfigurować pseudo-most, musiałeś podać zarówno odpowiednie trasy do obu stron mostu jak i stworzyć reguły pasujące dla proxy-ARP. Było to o tyle niewygodne, że wymagało wiele pisania, co przekładało się wprost na ilość możliwych do popełnienia błędów powodujących wzbudzanie się mostu do odpowiedzi ARP dla sieci, do których nie potrafił przetrasować pakietów.

Wraz z nadejściem Linuksa 2.4/2.5 (być może również 2.2) wycofano się z tego rozwiązania i zastąpiono je flagą w katalogu /proc nazwaną proxy_arp. Procedura na zbudowanie pseudo-mostu wygląda teraz tak:

1. Przydziel adresy IP obu interfejsom, `lewy' i `prawy'

2. Stwórz trasy tak, by twój komputer wiedział jakie komputery są po lewej a jakie po prawej stronie

3. Włącz proxy-ARP na obu interfejsach:

   echo 1 > /proc/sys/net/ipv4/conf/ethL/proxy_arp
   echo 1 > /proc/sys/net/ipv4/conf/ethP/proxy_arp
   

   gdzie `L' i `P' oznaczają interfejsy Lewy i Prawy
   
   

Nie zapomnij również ustawić flagi ip_forwarding! Podczas konwersji z prawdziwego mostu możesz stwierdzić że flaga była zgaszona ponieważ nie jest potrzebna podczas mostkowania.

Inna rzecz, którą możesz zauważyć to konieczność wyczyszczenia tablic podręcznych adresów ARP komputerów w sieci - może ona zawierać stare, pochodzące sprzed konfiguracji pseudo-mostu adresy sprzętowe, które nie są już aktualne.

Na sprzęcie firmy Cisco robi się to komendą clear arp-cache, pod Linuksem arp -d adres_ip. Możesz oczywiście również poczekać na to, by czas ich ważności wygasł sam, ale może to trochę zająć.

Możesz również przyśpieszyć ten proces używając narzędzia arping, które w wielu dystrybucjach znajduje się w pakiecie iputils. Za jego pomocą możesz wysłać samorzutnie rozgłoszenia ARP, nadpisując zdalne wpisy w pamięci podręcznej ARP.

Narzędzie to jest bardzo potężne, używane często przez `czarne kapelusze' do przekonfigurowywania twojego routingu!

Możesz również zauważyć, że twoja sieć jest źle skonfigurowana jeśli masz lub miałeś zwyczaj stosować trasy bez masek sieciowych. Dokładniej, niektóre wersje programu `route' poprawnie odgadywały maski a inne źle - bez powiadamiania cię o tym fakcie. Podczas wykonywania naprawdę chirurgicznego trasowania jak opisano powyżej, bardzo ważne jest sprawdzenie poprawności masek!

Założenia

Konfiguracja Zebry

Zajmijmy się taką siecią:

----------------------------------------------------
| 192.168.0.0/24                                   |
|                                                  |
|      Area 0       Przełączany Ethernet           |
|     (szkielet)          100BaseTX                |
----------------------------------------------------
   |           |                |              |
   |           |                |              |
   |eth1       |eth1            |eth0          |
   |100BaseTX  |100BaseTX       |100BaseTX     |100BaseTX
   |.1         |.2              |.253          |
---------   ------------   -----------      ------------------
|R Omega|   |R Atlantis|   |R Legolas|      |R Frodo         |
---------   ------------   -----------      ------------------
   |eth0         |eth0             |             |          |
   |             |                 |             |          |
   |2MbDSL/ATM   |100BaseTX        |10BaseT      |10BaseT   |
------------   ------------------------------------         |
| Internet |   | 172.17.0.0/16        Area 1      |         |
------------   |         Sieć w akademiku         |         |
               ------------------------------------         |10BaseT
                                                            |
                                              -------------------------------
                                              |  192.168.1.0/24 wlan  Area 2|
                                              |       sieć bezprzewodowa    |
                                              -------------------------------
              

Najpierw skonfigurujemy zebrę, dostosowując plik zebra.conf do naszych potrzeb:

hostname omega
password xxx 
enable password xxx
!
! Opis interfejsów
!
!interface lo
! description test opisu
!
interface eth1
multicast
!
! Statyczna trasa domyślna
!
ip route 0.0.0.0/0 212.170.21.129
!
log file /var/log/zebra/zebra.log

zebra=yes
ospfd=yes

hostname omega
password xxx
enable password xxx
!
router ospf
 network 192.168.0.0/24 area 0
 network 172.17.0.0/16 area 1
!
! log stdout
log file /var/log/zebra/ospfd.log

Uruchomienie Zebry

Wystartujemy teraz Zebrę; albo bezpośrednio z powłoki pisząc `zebra -d', albo za pomocą skryptu wykonując polecenie /etc/init.d/zebra start. Następnie obserwuj uważnie logi procesu ospdfd:

2002/12/13 22:46:24 OSPF: interface 192.168.0.1 join AllSPFRouters Multicast group.
2002/12/13 22:46:34 OSPF: SMUX_CLOSE with reason: 5   
2002/12/13 22:46:44 OSPF: SMUX_CLOSE with reason: 5
2002/12/13 22:46:54 OSPF: SMUX_CLOSE with reason: 5   
2002/12/13 22:47:04 OSPF: SMUX_CLOSE with reason: 5   
2002/12/13 22:47:04 OSPF: DR-Election[1st]: Backup 192.168.0.1
2002/12/13 22:47:04 OSPF: DR-Election[1st]: DR     192.168.0.1
2002/12/13 22:47:04 OSPF: DR-Election[2nd]: Backup 0.0.0.0
2002/12/13 22:47:04 OSPF: DR-Election[2nd]: DR     192.168.0.1
2002/12/13 22:47:04 OSPF: interface 192.168.0.1 join AllDRouters Multicast group.
2002/12/13 22:47:06 OSPF: DR-Election[1st]: Backup 192.168.0.2
2002/12/13 22:47:06 OSPF: DR-Election[1st]: DR     192.168.0.1
2002/12/13 22:47:06 OSPF: Packet[DD]: Negotiation done (Slave).
2002/12/13 22:47:06 OSPF: nsm_change_status(): scheduling new router-LSA origination
2002/12/13 22:47:11 OSPF: ospf_intra_add_router: Start

Możemy oczywiście połączyć się z interfejsem aplikacji zebra i ospfd wykonując:

$ telnet localhost zebra
lub
$ telnet localhost ospfd

root@atlantis:~# telnet localhost zebra
Trying 127.0.0.1...
Connected to atlantis.
Escape character is '^]'.

Hello, this is zebra (version 0.92a).
Copyright 1996-2001 Kunihiro Ishiguro.

User Access Verification

Password: 
atlantis> show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       B - BGP, > - selected route, * - FIB route

K>* 0.0.0.0/0 via 192.168.0.1, eth1
C>* 127.0.0.0/8 is directly connected, lo
O   172.17.0.0/16 [110/10] is directly connected, eth0, 06:21:53
C>* 172.17.0.0/16 is directly connected, eth0
O   192.168.0.0/24 [110/10] is directly connected, eth1, 06:21:53
C>* 192.168.0.0/24 is directly connected, eth1
atlantis> show ip ospf border-routers
============ OSPF router routing table =============
R    192.168.0.253         [10] area: (0.0.0.0), ABR
                            via 192.168.0.253, eth1
                           [10] area: (0.0.0.1), ABR
                            via 172.17.0.2, eth0

root@omega:~# ip route
212.170.21.128/26 dev eth0  proto kernel  scope link  src 212.170.21.172 
192.168.0.0/24 dev eth1  proto kernel  scope link  src 192.168.0.1 
172.17.0.0/16 via 192.168.0.2 dev eth1  proto zebra  metric 20 
default via 212.170.21.129 dev eth0  proto zebra 
root@omega:~#

Podpowiedź: możesz użyć:

tcpdump -i eth1 ip[9] == 89

OSPF ma wiele parametrów którymi można dostosować jego pracę, specjalnie jeśli mamy do czynienia z dużą siecią. W przyszłych wersjach tego HOWTO pokażemy zapewne metodologię dostosowywania OSPF.

Topologia przykładowej sieci

Poniższa topologia użyta zostanie do następnych przykładów. AS 1 i 50 mają więcej sąsiadów, ale będziemy konfigurować tylko je. Węzły w tym przykładzie komunikują się za pośrednictwem tuneli, ale w rzeczywistości nie jest to zupełnie potrzebne.

Uwaga: Numery AS użyte w tym przykładzie są zarezerwowane, jeśli chcesz uruchomić BGP w Internecie musisz zwrócić się do RIPE.

                  --------------------
                  | 192.168.23.12/24 |
                  |    AS: 23        |
                  --------------------
                    /             \
                   /               \
                  /                 \
        ------------------       ------------------
        | 192.168.1.1/24 |-------| 10.10.1.1/16   |
        |    AS: 1       |       |    AS: 50      |
        ------------------       ------------------

Przykładowa konfiguracja

Poniższa konfiguracja została napisana dla węzła 192.168.23.12/24 - względnie prosto jest ją zaadaptować na potrzeby innych węzłów.

Na początek konfigurujemy podstawowe parametry, takie jak nazwa hosta, hasło i ustawienia debugingu:

! nazwa hosta
hostname anakin

! hasło do logowania
password xxx

! hasło trybu enable (odpowiednik roota)
enable password xxx

! ścieżka do pliku z logami
log file /var/log/zebra/bgpd.log

! debugging: bardzo szczegółowy (oczywiście można
! później wyłączyć)
debug bgp events
debug bgp filters
debug bgp fsm
debug bgp keepalives
debug bgp updates

Następnie definiujemy listy dostępu, które posłużą nam do ograniczenia redystrybucji do tylko podsieci zdefiniowanych w RFC 1918 (prywatnych).

! sieci RFC 1918
access-list local_nets permit 192.168.0.0/16
access-list local_nets permit 172.16.0.0/12
access-list local_nets permit 10.0.0.0/8
access-list local_nets deny any

Następnym krokiem jest konfiguracja konkretnego AS:

! Nasz numer AS
router bgp 23

    ! Adres IP routera którym będzie się identyfikował
    bgp router-id 192.168.23.12

    ! Jakie sieci rozgłaszamy sąsiadom
    network 192.168.23.0/24

    ! Rozgłaszamy wszystkie sieci podłączone
    ! (bezpośrednio)
    redistribute connected

    ! Rozgłaszamy również trasy z tablicy kernela
    ! (wpisane ręcznie/statycznie)
    redistribute kernel

Każdy blok `router bgp' zawiera definicję konkretnego AS i listę sąsiadów do których podłączony jest nasz router.

    ! (sąsiad o IP 192.168.1.1 to AS 1)
    neighbor 192.168.1.1 remote-as 1
    ! (do tras otrzymywanych od tego sąsiada nałóż
    !  filtr `local_nets')
    neighbor 192.168.1.1 distribute-list local_nets in
    ! (sąsiad o IP 10.10.1.1 to AS 50)
    neighbor 10.10.1.1   remote-as 50
    ! (do tras otrzymywanych od tego sąsiada nałóż
    !  filtr `local_nets')
    neighbor 10.10.1.1   distribute-list local_nets in

Sprawdzanie konfiguracji

Uwaga: vtysh to multiplekser i służy do połączeń ze wszystkimi aktywnymi interfejsami Zebry.

anakin# sh ip bgp summary 
BGP router identifier 192.168.23.12, local AS number 23
2 BGP AS-PATH entries
0 BGP community entries

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.0.1       4    50      35      40        0    0    0 00:28:40        1
192.168.1.1     4     1   27574   27644        0    0    0 03:26:04       14

Total number of neighbors 2
anakin#
anakin# sh ip bgp neighbors 10.10.0.1
BGP neighbor is 10.10.0.1, remote AS 50, local AS 23, external link
  BGP version 4, remote router ID 10.10.0.1
  BGP state = Established, up for 00:29:01
  ....
anakin#

Sprawdźmy jakie trasy dostaliśmy od sąsiadów:

anakin# sh ip ro bgp 
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       B - BGP, > - selected route, * - FIB route

B>* 172.16.0.0/14 [20/0] via 192.168.1.1, tun0, 2d10h19m
B>* 172.30.0.0/16 [20/0] via 192.168.1.1, tun0, 10:09:24
B>* 192.168.5.10/32 [20/0] via 192.168.1.1, tun0, 2d10h27m
B>* 192.168.5.26/32 [20/0] via 192.168.1.1, tun0, 10:09:24
B>* 192.168.5.36/32 [20/0] via 192.168.1.1, tun0, 2d10h19m
B>* 192.168.17.0/24 [20/0] via 192.168.1.1, tun0, 3d05h07m
B>* 192.168.17.1/32 [20/0] via 192.168.1.1, tun0, 3d05h07m
B>* 192.168.32.0/24 [20/0] via 192.168.1.1, tun0, 2d10h27m
anakin#